NPM 6.9.1 is broken due to .git folder in published tarball

While this is clearly a bug, the default publish strategy is to publish all the contents of the package including dev&#x2F;test files. If you look at the node_modules tree on a typical server-side node project it&#x27;s full of garbage files.<p>We still think it&#x27;s a great idea to pull down hundreds if not thousands of copies of modules from a remote every time we generate a build. The community has always been lacking maturity around how it manages modules and releases code for production, preferring to preserve developer productivity and trinket features over best security practices and optimizing for the size and quality of production packages.<p>I don&#x27;t want to install hundreds of modules every time I create a new build. I don&#x27;t want your tests or your README in my production tarball. I don&#x27;t want your browser compatibility code in my server code. I don&#x27;t want my node_modules tree to be 9 layers deep. I don&#x27;t want to have to dedupe multiple copies of modules by hand. I don&#x27;t want to have to debug where shrinkwrap isn&#x27;t respected. I don&#x27;t want to play roulette with the package manager version to figure out which one does the right thing for my package. I don&#x27;t want to run your dubious pre&#x2F;post install scripts. I don&#x27;t want to use npm.<p>The sad thing is, npm is a commercial entity that has its package manager published by default with an opensource community project. And this is why we can&#x27;t have nice things.

Probably relevant-<p>This week&#x27;s Node.js weekly [1] mentions: &quot;Last week we mentioned the long awaited status of npm 6.9.1 and the possible ‘strike’ [2] in ongoing community work on the project, but npm’s Isaac Z. Schlueter has stepped up, got a release out&quot;<p>[1] <a href="https:&#x2F;&#x2F;nodeweekly.com&#x2F;issues&#x2F;294" rel="nofollow">https:&#x2F;&#x2F;nodeweekly.com&#x2F;issues&#x2F;294</a><p>[2] <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;aeschright&#x2F;8ed09cbc2a4aee00fcb4ad35086d76a6" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;aeschright&#x2F;8ed09cbc2a4aee00fcb4ad350...</a>

NPM still has bugs from v5 which haven&#x27;t been addressed and are ignored by it&#x27;s maintainers. Problems with `npm link` were never fixed. There is a discussion on the NPM tracker where the maintainers tell Substack that his ( very correct ) assessment of an issue was wrong and lock the thread.<p>It&#x27;s always the same usual suspects at NPM never accepting responsibility or blame for multiple incidents and ongoing quality issues.<p>NPM is currently on it&#x27;s last legs before acquisition or buyout.

I think this probably happens more often in other package repositories than we hear about it’s just that NPM is gigantic and people like to hate on JavaScript.<p>I’ve done stupid things too. I once committed the s3 keys to our public repo and had to explain why our s3 bill was so high. Never made that mistake again.

The interesting thing about semi-decentralized technologies is that every issue seems like a clusterfuck but it actually gets fixed fairly quickly and nobody in the future has to think about it at all

I see it&#x27;s been fixed by releasing 6.9.2.<p>Does this mean you can now &quot;brick&quot; people&#x27;s projects by sneaking npm@6.9.1 into their package.json?

These sort of bugs are hard to find with unit tests. But it&#x27;s still easy to test, to make sure it never happen again. I think it&#x27;s called integration tests. It can also be done with live testing, by checking all packages that lands on the public repository - if they include .git folder, passwords&#x2F;keys, or other credentials.

Bug aside, it baffles me that it&#x27;s a real person publishing rather than CI after tagging.

Software this popular doesn&#x27;t even run a test that installs, upgrades, then uninstalls before deployment? Isn&#x27;t that the most important thing the software needs to be able to do? Does NPM test anything at all before they release? Another reason to switch to yarn.

Fuckit.JS to the rescue?<p><a href="https:&#x2F;&#x2F;github.com&#x2F;mattdiamond&#x2F;fuckitjs&#x2F;blob&#x2F;master&#x2F;README.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mattdiamond&#x2F;fuckitjs&#x2F;blob&#x2F;master&#x2F;README.m...</a>