3 ms·

We did exactly this when packaging and deploying large node manifests at one of my former companies. Be super careful of removing large swaths of files. Out of

by lxe 3y ago

We did exactly this when packaging and deploying large node manifests at one of my former companies. Be super careful of removing large swaths of files. Out of 150,000 node modules in your manifest, I'm willing to bet at least one of them is doing something by reading one of these non-source files.

sbarre 3y ago
This was my concern as well. Looking at the script source, it's just matching globs, so there isn't much smarts to this. I'm sure it works most of the time, but yeah.. Do JS packages need some kind of .prodignore file similar to other .ignore files? So with a flag passed, after doing an npm install, there's a extra cleanup step that removes explicitly marked files that aren't needed for running in prod? (Not a fully formed idea, I'm sure I'm not thinking of drawbacks with this) Edit: this sort of exists as the .npmignore file? https://docs.npmjs.com/cli/v10/using-npm/developers#keeping-files-out-of-your-package https://docs.npmjs.com/cli/v10/using-npm/developers#keeping-...
- rezonant 3y ago
  .npmignore is the opposite of `files`, it omits files when creating the package itself, that's different than trimming the files when the package is installed. That said, files/npmignore is the correct way to deal with this and you should never remove files from the packages you install without extremely good reasons, and when you do it, it should be very narrowly scoped and handled automatically as part of npm install. It should be totally valid to delete node_modules and reinstall everything without causing problems. This is also the biggest reason to never commit node_modules, aside from the pure insanity of commiting hundreds of thousands of vendor managed files and inviting merge conflicts when two branches change those files...
QuadmasterXLII 3y ago
Test and bifurcate I guess.
- lxe 3y ago
  In production, preferably. This way you'll immediately find any issues and will have top priority allocated to fixing them.

by lxe 3y ago

sbarre 3y ago

This was my concern as well. Looking at the script source, it's just matching globs, so there isn't much smarts to this. I'm sure it works most of the time, but yeah.. Do JS packages need some kind of .prodignore file similar to other .ignore files? So with a flag passed, after doing an npm install, there's a extra cleanup step that removes explicitly marked files that aren't needed for running in prod? (Not a fully formed idea, I'm sure I'm not thinking of drawbacks with this) Edit: this sort of exists as the .npmignore file? https://docs.npmjs.com/cli/v10/using-npm/developers#keeping-files-out-of-your-package https://docs.npmjs.com/cli/v10/using-npm/developers#keeping-...

rezonant 3y ago
.npmignore is the opposite of `files`, it omits files when creating the package itself, that's different than trimming the files when the package is installed. That said, files/npmignore is the correct way to deal with this and you should never remove files from the packages you install without extremely good reasons, and when you do it, it should be very narrowly scoped and handled automatically as part of npm install. It should be totally valid to delete node_modules and reinstall everything without causing problems. This is also the biggest reason to never commit node_modules, aside from the pure insanity of commiting hundreds of thousands of vendor managed files and inviting merge conflicts when two branches change those files...

QuadmasterXLII 3y ago

Test and bifurcate I guess.

lxe 3y ago
In production, preferably. This way you'll immediately find any issues and will have top priority allocated to fixing them.