Rather than two giant 440px high images consisting of tiny text in the readme I'd quite love to read exactly what it does and why. Does it prune files in modules that are not needed? If so what heuristics does it use to prune files? Or does it prune modules that are not needed?<p>Reading the code[1] it appears to delete directories and extensions based on a blacklist.<p>1. <a href="https://github.com/tj/node-prune/blob/master/prune.go#L15-L51" rel="nofollow">https://github.com/tj/node-prune/blob/master/prune.go#L15-L5...</a>
Love it. Saved 600MB... and test cases still passed :)<p>I ported it to bash really quick, as thats probably easier for people to drop into their dotfiles if they don't have a Golang env setup.<p><a href="https://gist.github.com/gpittarelli/64d1e9b7c1a4af762ec467b1c7571dc2" rel="nofollow">https://gist.github.com/gpittarelli/64d1e9b7c1a4af762ec467b1...</a><p>If we all just do our part and send a PR setting up .npmignore for one or two of these projects, maybe we won't need this anymore
<a href="https://github.com/tj/node-prune/blob/master/prune.go#L57" rel="nofollow">https://github.com/tj/node-prune/blob/master/prune.go#L57</a><p>Doesn't this also result in .d.ts files being removed? These are type declaration files (Kinda like C's .h files) that provide types for you without the file size overhead of the full TypeScript source.
The Yarn autoclean command also does something like this: <a href="https://yarnpkg.com/lang/en/docs/cli/autoclean/" rel="nofollow">https://yarnpkg.com/lang/en/docs/cli/autoclean/</a>
Awesome idea. Especially if you’re packaging your projects via something like Docker this can shave hundreds of megabytes. (Even if you’re using the Docker layer cache, any change to your dependencies will bust the entire node_modules cache.)<p>The caveats is that this won’t work 100% of the time. There will be a dependency deep down in the tree that needs to read a markdown file from the file system or something of that sort. These issues could be hard to debug if this tool doesn’t provide good visibility into what’s being deleted.
Is this serious?<p>I mean, kudos for helping push node module developers to make better use of `.npmignore` et al, but this project strikes me as overly snarky or even trolling...<p>Seems like what we really need is for some volunteers to tackle the most-installed packages on npm that publish with many extraneous files.<p>Hell, you could even automate it by writing a bot that (politely) points out likely-extraneous files and opens a pull request with changes to `.npmignore` to clean things up... Hmm... Weekend project brewing...
No disrespect to TJ (he did many awesome projects I use almost daily), but wouldn't simple:
'find node_modules -not -regex ".*.[js,json]" -delete'<p>do the same job? Why project in go?
TJ, <a href="https://apex.sh/" rel="nofollow">https://apex.sh/</a> is so beautiful. Did you design it entirely yourself or did you get help and if so who helped? Also mind if I ask what your inspirations were?
I've been thinking about this in a different way: what about bundling things with rollup.js? Then each package in require() would be just a package.json and an index.js. I think this might even help with performance.<p>Edit: lightened up (;
Symptomatic of the npm community’s overloading of “npm install” to serve both users and contributors. It’s easy to configure “npm publish” to do essentially this for all users, but it’s considered bad practice. Which I don’t understand, since the dev use case is still fulfilled - and better - by “git clone”. And merging the two doesn’t scale - Chrome’s dev download is several GB and takes hours to build.
Usually I don't care about what language an executable is written in. After all, as a user I'm just interested in whether it executes or not.<p>But these small-software situations amaze me. Someone with a node_modules problem will have readily available sh, node and maybe python. So why golang? What could those not do, or golang can do better to such extent that it trumps availability? Similarly there's a price to pay in terms of people contributing with a fix: who is interested in pruning node_modules and will send in a golang PR?<p>In other words, if a dev would prefer Java (specifically chosen because it exacerbates the startup time), would it still pass as ok? Luckily golang can compile to binaries but that implies you give up availability on the other end, now being confined to someone compiling and publishing on a regular basis, as opposed to just pushing a fix commit to a git url.<p>None of the above would be of importance if this would be a personal-quality repo with a note: hey i did this at 2am out of frustration, i chose the tools that i knew best, use it at your own risk, opensourced to share knowledge and to access it from my own projects, not as a "productified" software.<p>EDIT: I would much prefer a commenter's solution in sh for the reasons above but also readibility: <a href="https://gist.github.com/gpittarelli/64d1e9b7c1a4af762ec467b1c7571dc2" rel="nofollow">https://gist.github.com/gpittarelli/64d1e9b7c1a4af762ec467b1...</a> :clap:
This is completely useless because npm still downloads those files and the hdd space is pretty negligeble. It should def go under the category of troll driven development. This might be useful for docker images that will be distrubuted and will be downloaded a lot, but even there it's a stretch.<p>That being said, it would be great if npm had some functionality around packaging only the necessary files for actually running the module and removing all unnecessary files (tests, source code, documentation) and have an opt-in option to install those.