31–40 of 66 posts
https://github.com/tj/node-prune/blob/master/prune.go#L57 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.
TJ, https://apex.sh/ 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?
Thanks! I do all the design stuff myself. I wouldn't call myself a designer, but I do enjoy it either way!
Edit: lightened up (;
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?
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.
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.
EDIT: I would much prefer a commenter's solution in sh for the reasons above but also readibility: https://gist.github.com/gpittarelli/64d1e9b7c1a4af762ec467b1... :clap:
The Yarn autoclean command also does something like this: https://yarnpkg.com/lang/en/docs/cli/autoclean/
// Copied from yarn (mostly).
Is this serious? 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... Seems like what we really need is for some volunteers to tackle the most-installed packages on npm that publish with many extraneous files. Hell, you could even automate it by writing a bot that (politely) points out likely-extraneous files a…
It's not a troll, this is for AWS Lambda, where size impacts deployments and cost starts. See my comment below about the automation, I think it could/should be done too!
Love it. Saved 600MB... and test cases still passed :) 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. https://gist.github.com/gpittarelli/64d1e9b7c1a4af762ec467b1... 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
do the same job? Why project in go?
Earlier quoted context omitted.
It's not a troll, this is for AWS Lambda, where size impacts deployments and cost starts. See my comment below about the automation, I think it could/should be done too!
Wouldnt it make more sense to bundle, minify and treeshake your package than to delete unused files in node_modules? Tree shaking will remove unsused code even from files you are using.
https://github.com/tj/node-prune/blob/master/prune.go#L57 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.
They aren't needed during runtime though, that's what this project is attempting to clean up.