Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
I can't really think of a compelling reason to remove node_modules as a matter of course. The most compelling one, is what you alluded to. If node_modules is "corrupted" in some manner, removing a...
Answer
#2: Post edited
by
Derek Elkins
·
2020-12-25T01:48:39Z (almost 4 years ago)
The second scenario I described in the original version shouldn't be able to happen.
- I can't really think of a compelling reason to remove `node_modules` as a matter of course.
Here are the two best reasons I can think of.The first, and less compelling one, is what you alluded to. If `node_modules` is "corrupted" in some manner, removing and refetching it will resolve that "corruption" without needing any manual intervention. Short of a malicious attack, it's unlikely that you will fail to notice such "corruption" unless it really doesn't matter (e.g. corrupts code that you don't use). Still, if this was a concern, calculating a secure hash of `node_modules` and verifying it would be a cheaper (though still fairly expensive) and more reliable method to check this (it's immune from upstream attacks assuming you trust the original versions you hash).The second, and slightly more compelling reason, is ensuring that all dependencies are declared. In particular, if, for some reason, you already had a (partially) populated `node_modules` folder that included dependencies that aren't declared in your `package.json`/`package-lock.json`. If you removed the `node_modules` folder, then these undeclared dependencies would quickly become evident. If you didn't, then you may only find out when you project mysteriously fails to build in a different environment. In practice, I don't think this is too likely to happen and isn't worth the cost of refetching `node_modules` every build to avoid. Again, there are cheaper ways of dealing with this if you really were concerned about it.I would say *assuming there are no costs* and particularly that no one is bottle-necked on waiting for builds to complete, then endeavoring to ensure a consistent and clean build environment is typically preferable.
- I can't really think of a compelling reason to remove `node_modules` as a matter of course.
- The most compelling one, is what you alluded to. If `node_modules` is "corrupted" in some manner, removing and refetching it will resolve that "corruption" without needing any manual intervention. Short of a malicious attack, it's unlikely that you will fail to notice such "corruption" unless it really doesn't matter (e.g. corrupts code that you don't use). Still, if this was a concern, calculating a secure hash of `node_modules` and verifying it would be a cheaper (though still fairly expensive) and more reliable method to check this (it's immune from upstream attacks assuming you trust the original versions you hash). `npm install` does not verify the integrity of the `node_modules` directory. It only verifies the integrity of the tarballs it downloads.
- An important point to note is that `npm install` will *remove* packages that are not in the `package.json`/`package-lock.json`/`npm-shrinkwrap.json`. Packages from earlier builds or otherwise present that are not explicitly depended upon will thus be removed avoiding depending on undeclared dependencies. This also avoids the need to manually clean up no longer necessary packages.
- I would say *assuming there are no costs* and particularly that no one is bottle-necked on waiting for builds to complete, then endeavoring to ensure a consistent and clean build environment is typically preferable. It's certainly the safer, if more expensive, default.
#1: Initial revision
by
Derek Elkins
·
2020-12-23T23:26:48Z (almost 4 years ago)
I can't really think of a compelling reason to remove `node_modules` as a matter of course. Here are the two best reasons I can think of. The first, and less compelling one, is what you alluded to. If `node_modules` is "corrupted" in some manner, removing and refetching it will resolve that "corruption" without needing any manual intervention. Short of a malicious attack, it's unlikely that you will fail to notice such "corruption" unless it really doesn't matter (e.g. corrupts code that you don't use). Still, if this was a concern, calculating a secure hash of `node_modules` and verifying it would be a cheaper (though still fairly expensive) and more reliable method to check this (it's immune from upstream attacks assuming you trust the original versions you hash). The second, and slightly more compelling reason, is ensuring that all dependencies are declared. In particular, if, for some reason, you already had a (partially) populated `node_modules` folder that included dependencies that aren't declared in your `package.json`/`package-lock.json`. If you removed the `node_modules` folder, then these undeclared dependencies would quickly become evident. If you didn't, then you may only find out when you project mysteriously fails to build in a different environment. In practice, I don't think this is too likely to happen and isn't worth the cost of refetching `node_modules` every build to avoid. Again, there are cheaper ways of dealing with this if you really were concerned about it. I would say *assuming there are no costs* and particularly that no one is bottle-necked on waiting for builds to complete, then endeavoring to ensure a consistent and clean build environment is typically preferable.