-
Notifications
You must be signed in to change notification settings - Fork 243
[RRFC] .npmignore
pragma to include .gitignore
#363
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
I think this is pretty useful. The challenge will be to find a syntax that would indeed make the npm CLI crash prior to supporting this feature. Globs are very accommodating, unfortunately, since filenames on posix systems can contain almost any character. I don't see anything offhand that will make |
Another alternative would be to make a new filename, that when present causes npmignore to be ignored - but i have no brilliant suggestions for a name for it :-/ |
Hm, not seeing how that would fix the make-work of adding something to both .gitignore and .npmignore. I'm reminded somewhat of https://xkcd.com/927/ 😂 |
Yeah, fair point - for npm back compat i'd still need to maintain an npmignore in that case, so that's probably not a viable solution. |
Motivation ("The Why")
While opinions differ, I consider "files" to be dangerous, since I have zero concern for accidental publishing but I have infinite concern for accidental breakage. (Let's avoid debating this)
When using
.npmignore
, one has to remember to start bycp .gitignore .npmignore
, and then later, to keep those in sync, since unfortunately npm ignores .gitignore when .npmignore is present. This is a maintenance burden and is error-prone over time.Example/How/Desired Behavior
These examples show a hypothetical where "coverage data" is ignored by both git and npm, but the "dist" folder (build output) is ignored by git but included in npm.
Current:
.gitignore
.npmignore
coverage/ # coverage data
Potential:
.gitignore
.npmignore
The advantage would be that additions to
.gitignore
no longer need to be propagated to.npmignore
. The disadvantage would be that removals from.gitignore
now do need to be propagated, but the explicit opt-in would mean that's expected.Thoughts?
The text was updated successfully, but these errors were encountered: