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 suspect this is an outdated practice: Prior to npm 3, npm did not keep track of resolved dependencies, and npm install would try to reconcile the existing with the declared dependencies. Since no...
Answer
#2: Post edited
by
meriton
·
2020-12-24T23:58:50Z (over 3 years ago)
- I suspect this is an outdated practice:
- Prior to npm 3, npm did not keep track of resolved dependencies, and npm install would try to reconcile the existing with the declared dependencies. Since `node_modules` is not commonly under version control, this meant that the build would depend on hidden state, and therefore be non-reproducible. Back then, the easiest and most reliable way to ensure reproducible builds was deleting `node_modules`.
Since npm 3, npm keeps track of resolved dependencies in `package-lock.json`, thereby guaranteeing that the same dependency versions are used irrespective of the prior state of `node_modules` (this even works if the registry is updated retroactively, which sometimes happens to fix high priority security issues).- Nowadays, the only benefit of deleting `node_modules` would be to guard against software other than npm tampering with its contents - but nobody should do that (and if somebody has hacked your build server, you probably have bigger problems ...)
- I suspect this is an outdated practice:
- Prior to npm 3, npm did not keep track of resolved dependencies, and npm install would try to reconcile the existing with the declared dependencies. Since `node_modules` is not commonly under version control, this meant that the build would depend on hidden state, and therefore be non-reproducible. Back then, the easiest and most reliable way to ensure reproducible builds was deleting `node_modules`.
- Since npm 3, npm keeps track of resolved dependencies in `package-lock.json`, thereby guaranteeing that the same dependency versions are used irrespective of the prior state of `node_modules` (this should even work if the registry is updated retroactively, which sometimes happens to fix high priority security issues).
- Nowadays, the only benefit of deleting `node_modules` would be to guard against software other than npm tampering with its contents - but nobody should do that (and if somebody has hacked your build server, you probably have bigger problems ...)
#1: Initial revision
by
meriton
·
2020-12-24T23:57:23Z (over 3 years ago)
I suspect this is an outdated practice: Prior to npm 3, npm did not keep track of resolved dependencies, and npm install would try to reconcile the existing with the declared dependencies. Since `node_modules` is not commonly under version control, this meant that the build would depend on hidden state, and therefore be non-reproducible. Back then, the easiest and most reliable way to ensure reproducible builds was deleting `node_modules`. Since npm 3, npm keeps track of resolved dependencies in `package-lock.json`, thereby guaranteeing that the same dependency versions are used irrespective of the prior state of `node_modules` (this even works if the registry is updated retroactively, which sometimes happens to fix high priority security issues). Nowadays, the only benefit of deleting `node_modules` would be to guard against software other than npm tampering with its contents - but nobody should do that (and if somebody has hacked your build server, you probably have bigger problems ...)