4 ms·

As shitty as unpublishing is, I think the best thing the npm community needs to take away from this is auto updating is bad. Remove the ~ and ^ from your depend

As shitty as unpublishing is, I think the best thing the npm community needs to take away from this is auto updating is bad. Remove the ~ and ^ from your dependencies so that only a package of a specific version can be installed. "This or better" thinking doesn't work if "better" is unknown. I know that the version I am using currently is fine but I don't know about future updates. Even if we had signed packages, we are still installing unknown software if we just trust other devs. I lock my dependency version and then use https://www.npmjs.com/package/npm-check-updates https://www.npmjs.com/package/npm-check-updates to figure out what needs updating, then I test my code. This should not be done as an automatic part of the build process. *edited npm capitalization

Klathmon 11y ago
No need to muck about with your package.JSON, actually fix the problem by just checking in your node_modules folder. Then continue working like you always have. There are some changes that you'll need of you are using native modules, but they are simple and easy to do.
- AgentME 11y ago
  You can use shrinkpack[1] to solve the issues with native modules. It allows you to check in the archives that npm downloads instead of the installed node_modules folder. [1]: https://github.com/JamieMason/shrinkpack https://github.com/JamieMason/shrinkpack
  - Klathmon 11y ago
    That's a great solution, but i was just talking about installing the source into node_modules and running `npm rebuild` instead of `npm install` when you install your app.
kylehotchkiss 11y ago
By adding `save-exact=true` to .npmrc in a project NPM saves the exact version. Learned this trying to fix Shrinkwrap a few weeks back but seems like it's a good practice for securities sake now.
AgentME 11y ago
This doesn't lock the versions of your sub-dependencies. `npm shrinkwrap` exists to do that. Applications should use it to pin the versions of all of their dependencies and sub-dependencies.
- dustinmoorenet 11y ago
  Yes, and updates of sub dependencies have bitten me before. I will look into shrinkwrap.
spankalee 11y ago
Dependency version ranges should be a _wide_ as possible, so that users of your libraries have flexibility when selecting versions. Rather than artificially constrict your version ranges, NPM should support real version locking, and applications should check in their lock file.
- elclanrs 11y ago
  Do you mean like npm's shrinkwrap [1]? [1] https://docs.npmjs.com/cli/shrinkwrap https://docs.npmjs.com/cli/shrinkwrap
- dustinmoorenet 11y ago
  Known ranges are fine. e.g. It is fine to accept known published versions 0.0.1 to 0.0.4, but not unknown future versions 0.0.5 and up, which ^ and ~ allow.

Klathmon 11y ago

No need to muck about with your package.JSON, actually fix the problem by just checking in your node_modules folder. Then continue working like you always have. There are some changes that you'll need of you are using native modules, but they are simple and easy to do.

AgentME 11y ago
You can use shrinkpack[1] to solve the issues with native modules. It allows you to check in the archives that npm downloads instead of the installed node_modules folder. [1]: https://github.com/JamieMason/shrinkpack https://github.com/JamieMason/shrinkpack
- Klathmon 11y ago
  That's a great solution, but i was just talking about installing the source into node_modules and running `npm rebuild` instead of `npm install` when you install your app.

kylehotchkiss 11y ago

By adding `save-exact=true` to .npmrc in a project NPM saves the exact version. Learned this trying to fix Shrinkwrap a few weeks back but seems like it's a good practice for securities sake now.

AgentME 11y ago

This doesn't lock the versions of your sub-dependencies. `npm shrinkwrap` exists to do that. Applications should use it to pin the versions of all of their dependencies and sub-dependencies.

dustinmoorenet 11y ago
Yes, and updates of sub dependencies have bitten me before. I will look into shrinkwrap.

spankalee 11y ago

Dependency version ranges should be a _wide_ as possible, so that users of your libraries have flexibility when selecting versions. Rather than artificially constrict your version ranges, NPM should support real version locking, and applications should check in their lock file.

elclanrs 11y ago
Do you mean like npm's shrinkwrap [1]? [1] https://docs.npmjs.com/cli/shrinkwrap https://docs.npmjs.com/cli/shrinkwrap
dustinmoorenet 11y ago
Known ranges are fine. e.g. It is fine to accept known published versions 0.0.1 to 0.0.4, but not unknown future versions 0.0.5 and up, which ^ and ~ allow.