4 ms·

Yarn was great and all, but it’s not npm so you have to convince the whole team to use it. I can’t believe npm still sucks after 10 years. Week doesn’t go by I

by rudian 5y ago

Yarn was great and all, but it’s not npm so you have to convince the whole team to use it. I can’t believe npm still sucks after 10 years. Week doesn’t go by I have to nuke node_modules and occasionally the lock as well. It’s junk as far as I’m concerned, but I just happen to know what the problem is every time.

eh9 5y ago
Has it been a hard sell in your experience?
- xzel 5y ago
  I don’t think in general I’ve ever had a hard time selling it. The issue is the decision pretty much all or nothing; everyone has to be using it as well. Getting a number of people to switch is always difficult.
  - gavinray 5y ago
    I've had repos where coworkers refused to use yarn, and would commit NPM's lock file Locally I just delete it and use yarn for all my commands, and they can use NPM for their commands. It doesn't make much of a difference, not actually sure what the problem is. Nobody would even know whether you're using yarn or NPM if you don't commit a lockfile I suppose
    - arcatek 5y ago
      Note that we don't recommend using both Yarn and npm: both have different feature sets, heuristics, and implementation details, and as a result your colleagues and you may have slightly different behaviors in development (on top of desync'd dependency trees). Just like no one would think of letting their developers choose whether they want to bundle their code using either Webpack or Rollup, the package manager should really be enforced at the project level, whether you choose Yarn or npm.
      - gavinray 5y ago
        I understand that there are probably some weird edge cases where this could cause an issue But I've been doing this for years and so far haven't ran into it I really don't have the mental energy to fight with people over package managers -- it's just not worth it. > your colleagues and you may have slightly different behaviors in development (on top of desync'd dependency trees). Yarn and NPM both take a "package.json" and install the dependencies so that you can import them though. If I have "express" in my package.json and do "npm install" or "yarn install" -- the functional outcome is (and always should be) the same Unless you're using some package-manager specific behavior so that it only works properly or relies on particularities from either yarn/npm/pnpm whatnot, I'm not sure I understand how this could cause problems But also, you're the lead maintainer of Yarn and I'm just some schmuk who's been on the consuming end for the last many years. I reckon you've got a fair bit more clue here than I do.
    - smt88 5y ago
      Your team's practice of failing to commit lockfiles is risky and (as far as I know) uncommon. Commit your lockfiles. Their whole point is to reduce the risk of dependencies silently breaking your build. If you don't run tests in your production environment (and most people don't), then you need to commit a lockfile and use it when deploying.
jbverschoor 5y ago
unfortunately there's no way to nuke npm
ruffrey 5y ago
I hear stories like this occasionally. I've used node heavily at every day job for about 9 years. Needing to blow away node modules is so rare. Even on large teams with nested package.json files. With npm link and library development. Once npm added the lock file instead of shrinkwrap, it became a total non issue. I am genuinely curious what are the specific issues which necessitate deleting all modules? Colleagues across operating systems with native modules? Old node versions?
- DangitBobby 5y ago
  The specific issue tends to be "I just installed a new package and now I get esoteric import errors." Blow away node_modules and it's magically fixed.
- andrewmcwatters 5y ago
  Take React.js's "Add React to a Website" article[1] for example. The example of adding JSX to an existing website[2]... breaks! And you won't exactly know when until it does and you have to delete your package-lock.json file. It should work the first time, but once you commit those package versions, running `npx babel [...]` may break depending on what is in your package-lock.json file, and when. Why? Because installing the dependencies they specify and running babel (implicitly at the latest version) does not have reproducible results. It's that simple. package-lock.json is specifically supposed to help with this, but in some cases, it just doesn't, and it's entirely possible, and common(!) to have two sets of package.json files produce differing package-lock.json files. They even have a warning below that can still occur even if you already have the dependencies specified above installed: > If you see an error message saying “You have mistakenly installed the babel package”, you might have missed the previous step. Perform it in the same folder, and then try again. [1]: https://reactjs.org/docs/add-react-to-a-website.html https://reactjs.org/docs/add-react-to-a-website.html [2]: https://reactjs.org/docs/add-react-to-a-website.html#add-jsx-to-a-project https://reactjs.org/docs/add-react-to-a-website.html#add-jsx...

by rudian 5y ago

eh9 5y ago

Has it been a hard sell in your experience?

xzel 5y ago
I don’t think in general I’ve ever had a hard time selling it. The issue is the decision pretty much all or nothing; everyone has to be using it as well. Getting a number of people to switch is always difficult.
- gavinray 5y ago
  I've had repos where coworkers refused to use yarn, and would commit NPM's lock file Locally I just delete it and use yarn for all my commands, and they can use NPM for their commands. It doesn't make much of a difference, not actually sure what the problem is. Nobody would even know whether you're using yarn or NPM if you don't commit a lockfile I suppose
  - arcatek 5y ago
    Note that we don't recommend using both Yarn and npm: both have different feature sets, heuristics, and implementation details, and as a result your colleagues and you may have slightly different behaviors in development (on top of desync'd dependency trees). Just like no one would think of letting their developers choose whether they want to bundle their code using either Webpack or Rollup, the package manager should really be enforced at the project level, whether you choose Yarn or npm.
    - gavinray 5y ago
      I understand that there are probably some weird edge cases where this could cause an issue But I've been doing this for years and so far haven't ran into it I really don't have the mental energy to fight with people over package managers -- it's just not worth it. > your colleagues and you may have slightly different behaviors in development (on top of desync'd dependency trees). Yarn and NPM both take a "package.json" and install the dependencies so that you can import them though. If I have "express" in my package.json and do "npm install" or "yarn install" -- the functional outcome is (and always should be) the same Unless you're using some package-manager specific behavior so that it only works properly or relies on particularities from either yarn/npm/pnpm whatnot, I'm not sure I understand how this could cause problems But also, you're the lead maintainer of Yarn and I'm just some schmuk who's been on the consuming end for the last many years. I reckon you've got a fair bit more clue here than I do.
  - smt88 5y ago
    Your team's practice of failing to commit lockfiles is risky and (as far as I know) uncommon. Commit your lockfiles. Their whole point is to reduce the risk of dependencies silently breaking your build. If you don't run tests in your production environment (and most people don't), then you need to commit a lockfile and use it when deploying.

jbverschoor 5y ago

unfortunately there's no way to nuke npm

ruffrey 5y ago

I hear stories like this occasionally. I've used node heavily at every day job for about 9 years. Needing to blow away node modules is so rare. Even on large teams with nested package.json files. With npm link and library development. Once npm added the lock file instead of shrinkwrap, it became a total non issue. I am genuinely curious what are the specific issues which necessitate deleting all modules? Colleagues across operating systems with native modules? Old node versions?

DangitBobby 5y ago
The specific issue tends to be "I just installed a new package and now I get esoteric import errors." Blow away node_modules and it's magically fixed.
andrewmcwatters 5y ago
Take React.js's "Add React to a Website" article[1] for example. The example of adding JSX to an existing website[2]... breaks! And you won't exactly know when until it does and you have to delete your package-lock.json file. It should work the first time, but once you commit those package versions, running `npx babel [...]` may break depending on what is in your package-lock.json file, and when. Why? Because installing the dependencies they specify and running babel (implicitly at the latest version) does not have reproducible results. It's that simple. package-lock.json is specifically supposed to help with this, but in some cases, it just doesn't, and it's entirely possible, and common(!) to have two sets of package.json files produce differing package-lock.json files. They even have a warning below that can still occur even if you already have the dependencies specified above installed: > If you see an error message saying “You have mistakenly installed the babel package”, you might have missed the previous step. Perform it in the same folder, and then try again. [1]: https://reactjs.org/docs/add-react-to-a-website.html https://reactjs.org/docs/add-react-to-a-website.html [2]: https://reactjs.org/docs/add-react-to-a-website.html#add-jsx-to-a-project https://reactjs.org/docs/add-react-to-a-website.html#add-jsx...