-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: npm ignore several files used for dev #137
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR.
These changes to files inlcuded in packaging look good to me!
@tlhunter Another option would be to use the "files" property of package.json to explicitly allow-list the files to include. For example, with: diff --git a/package.json b/package.json
index 45d4a06..a8ae4f2 100644
--- a/package.json
+++ b/package.json
@@ -23,6 +23,12 @@
"hook",
"hooks"
],
+ "files": [
+ "lib",
+ "*.js",
+ "*.mjs",
+ "*.d.ts"
+ ],
"author": "Bryan English <[email protected]>",
"license": "Apache-2.0",
"bugs": { the published files will be:
|
If "files" is considered, then we'd have the same discussion about what files to publish that aren't strictly needed for runtime. My bias would be to include:
Nothing else.
This is only required for the tests, AFAICT -- for the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said (my comments about the "files" option), this is definitely an improvement. Thanks.
I'd be against using It would be very easy to add source files and forget to update |
Although now I'm looking again I see the wildcard/glob paths for
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the test files may need to be present for citgm to work. 🤔
Before the days of ubiquitous CI and publishing via CI, and the first time I I think either is fine. |
It's in the lookup config here: https://github.com/nodejs/citgm/blob/main/lib/lookup.json#L214-L218 Presumably that means it's using |
Hrm. Looking at a few other packages that are listed in that config file: none of |
From a perhaps naive read of citgm, my guess is that:
So, I think dropping tests from the published IITM will be fine and if not, the fix in citgm will be trivial. |
Maintaining |
I'm fine just landing this as-is and if CITGM breaks we can revert. Seems like it should probably be fine, but I'm not 100% confident of that.
I think it should be expected those need to be maintained separately. They have two entirely different targets. 🤷🏻 |
I noticed that there are many files included in the npm package that aren't necessary at run time, even from when Datadog was still doing releases.
Definitely open to conversation about these changes.
1.8.1
1.9.0