3 ms·

Doesn't specifying a "version" in your package.json completely solve this problem? Can an author replace a package without changing its version on npm?

Klathmon 8y ago
>Can an author replace a package without changing its version on npm? No, and now both npm and Yarn have lockfiles, meaning you lock in the exact version of all dependencies (including transitive dependencies). The ecosystem saw the issues that were starting to crop up, and fairly quickly created solutions that are now in widespread usage.
- specialist 8y ago
  I have a great deal of antipathy towards npm and lock files. I don't understand how rerunning shrinkwrap can change the roster. And I don't care enough to spend any more effort trying to figure it out. (Meaning, fresh out of goodwill.) Maybe yarn is better. I kicked its tires; seemed okay. Alas, we have too many (more than zero) nodejs projects to do a clean switch, and I'm tired of pushing rope. But even if yarn is better... I just can't grasp how we got to this point, or how any one involved thought any of this was acceptable, on any level.
  - paulddraper 8y ago
    Shrinkwrap < npm lock < yarn lock
    - specialist 8y ago
      Belated thanks to you & Klathmon. Just yesterday I learned about NPM 6.x's new lock files. I'll suspend disbelief and give it another whirl.
  - Klathmon 8y ago
    Well luckily newer versions of npm and all versions of yarn handle the lockfiles for you, no extra effort required at all. If you install something, it will find and lock the dependency versions at install time. When you update that dependency, it will repeat then lock in again. You actually have to go out of your way now to not use lockfiles in the js ecosystem. And if you really do have some js projects, take 30 minutes and look into yarn. Not only is it significantly faster in my experience, but it's also mostly a drop-in replacement and provides some much needed features like the ability to install while offline from a local cache, and interactive upgrade tools.
    - specialist 8y ago
      Belated thanks to you & paulddraper. Just yesterday I learned about NPM 6.x's new lock files. I'll suspend disbelief and give it another whirl.
      - Klathmon 8y ago
        That's great! But I would like to give you a warning that I personally don't use npm any more. While they have improved leaps and bounds, in my opinion they are still far behind yarn in many areas. Yarn has deterministic installs, an offline cache (the recent yarn/npm registry downtime of like an hour didn't stop our devs from reinstalling dependencies because they were in the offline cache), fantastic tooling around license checking and validations, and the workspaces system which makes it significantly easier to work with massive monorepos with multiple sub-packages. If you are in a willing mood, and are already spending the time to try npm again, I highly encourage you to give yarn a shot as well. You can install it with `npm install yarn --global` if you want to just try it out (they have a ton of more robust install methods to choose from if you want to permanently switch), and aside from some different names (like you use `yarn add dependency-name` instead of `npm install dependency-name --save`), it's mostly a drop-in replacement and can even happily work alongside npm (one of the packages I maintain we provide both an npm lockfile and a yarn lockfile quite easily, while using yarn internally). Hell just last week I used yarn to force a transitive dependency (it was like 4 levels deep in my dependency graph) to upgrade to a version which fixed a security issue in a library I maintain, then put that in the lockfile so all users that install that dependency through my package now get the updated version by default. Still, kudos for being open to trying it again! npm has never been the best package manager by any account, but the one thing they do really well is improve.

Klathmon 8y ago

>Can an author replace a package without changing its version on npm? No, and now both npm and Yarn have lockfiles, meaning you lock in the exact version of all dependencies (including transitive dependencies). The ecosystem saw the issues that were starting to crop up, and fairly quickly created solutions that are now in widespread usage.

specialist 8y ago
I have a great deal of antipathy towards npm and lock files. I don't understand how rerunning shrinkwrap can change the roster. And I don't care enough to spend any more effort trying to figure it out. (Meaning, fresh out of goodwill.) Maybe yarn is better. I kicked its tires; seemed okay. Alas, we have too many (more than zero) nodejs projects to do a clean switch, and I'm tired of pushing rope. But even if yarn is better... I just can't grasp how we got to this point, or how any one involved thought any of this was acceptable, on any level.
- paulddraper 8y ago
  Shrinkwrap < npm lock < yarn lock
  - specialist 8y ago
    Belated thanks to you & Klathmon. Just yesterday I learned about NPM 6.x's new lock files. I'll suspend disbelief and give it another whirl.
- Klathmon 8y ago
  Well luckily newer versions of npm and all versions of yarn handle the lockfiles for you, no extra effort required at all. If you install something, it will find and lock the dependency versions at install time. When you update that dependency, it will repeat then lock in again. You actually have to go out of your way now to not use lockfiles in the js ecosystem. And if you really do have some js projects, take 30 minutes and look into yarn. Not only is it significantly faster in my experience, but it's also mostly a drop-in replacement and provides some much needed features like the ability to install while offline from a local cache, and interactive upgrade tools.
  - specialist 8y ago
    Belated thanks to you & paulddraper. Just yesterday I learned about NPM 6.x's new lock files. I'll suspend disbelief and give it another whirl.
    - Klathmon 8y ago
      That's great! But I would like to give you a warning that I personally don't use npm any more. While they have improved leaps and bounds, in my opinion they are still far behind yarn in many areas. Yarn has deterministic installs, an offline cache (the recent yarn/npm registry downtime of like an hour didn't stop our devs from reinstalling dependencies because they were in the offline cache), fantastic tooling around license checking and validations, and the workspaces system which makes it significantly easier to work with massive monorepos with multiple sub-packages. If you are in a willing mood, and are already spending the time to try npm again, I highly encourage you to give yarn a shot as well. You can install it with `npm install yarn --global` if you want to just try it out (they have a ton of more robust install methods to choose from if you want to permanently switch), and aside from some different names (like you use `yarn add dependency-name` instead of `npm install dependency-name --save`), it's mostly a drop-in replacement and can even happily work alongside npm (one of the packages I maintain we provide both an npm lockfile and a yarn lockfile quite easily, while using yarn internally). Hell just last week I used yarn to force a transitive dependency (it was like 4 levels deep in my dependency graph) to upgrade to a version which fixed a security issue in a library I maintain, then put that in the lockfile so all users that install that dependency through my package now get the updated version by default. Still, kudos for being open to trying it again! npm has never been the best package manager by any account, but the one thing they do really well is improve.