rfcs
rfcs copied to clipboard
npm
[RRFC] remove `npm-shrinkwrap.json` from the list of unignorable files
Motivation ("The Why")
I have npm-shrinkwrap.json in both .gitignore and .npmignore on basically all of my repos. However, I unknowingly broke ls-engines when I published it, not realizing that the npm-shrinkwrap.json i'd been playing with would be published despite being explicitly ignored.
Possible solutions
- allow
npm-shrinkwrap.jsonto be npmignored - fail a publish when an unignorable file is explicitly ignored, via "files" or ".npmignore" or ".gitignore"
The upsides
- it would be much harder to accidentally break consumers by publishing a shrinkwrap (something that's a long-standing bad practice anyways)
The downsides
- someone who wants to publish a shrinkwrap would only be able to do so if they weren't already explicitly ignoring it.
Can anyone provide any scenario where making one of the above changes would pose problems for someone?
Shouldn't a package-lock be used in the case of a shrinkwrap you don't want published?
@dominykas yes, when such a lockfile is intentionally present. In my case, my package actually interacts with other projects' shrinkwrap files, so I'd generated one for testing - but because it was in npmignore, I assumed it would be ignored by npm.
following up from our OpenRFC talk today: npm-shrinkwrap.json being part of the list of unignorable files is a long standing contract that is expected by (at least) some subset of the ecosystems that npm caters to. I'm on the side that completely removing it from that list is too much of a breaking change for too little of an upside (from my pov the subset of package authors that would publish a package containing a npm-shrinkwrap.json unintentionally is much smaller than the subset of package authors intentionally using it).
On the other hand I'm open to the alternative of making it ignorable via adding to .npmignore (and/or possibly .gitignore) - if the file is listed there it looks to me that the user intent is very clear.
I remain convinced that the subset of the infinitesimal number of packages intentionally published with a shrinkwrap file, using files, and not explicitly including it in files, is in the single digits, but I understand it would still technically be a breaking change.