4 ms·

This is idiotic and could only be written by someone that have no idea about node package managements. 1. Most of CI systems have better options for caching no

This is idiotic and could only be written by someone that have no idea about node package managements. 1. Most of CI systems have better options for caching node modules[1][2]. When you check node_modules, you add fixed cost(increasing) for every commit. When you use CI caching you add fixed cost(static) to only small number of builds. 2. Once you start upgrading packages repo size will continue to grow. At some point you will be forced to git filter out node_modules. You will lose the ability to run locally older commits. 3. You will need to pin version of npm/yarn because structure of node_modules depends on hoisting algorithm. Every upgrade of node will be extra painful because you also potentially need to upgrade all yours packages. 4. Platform dependent modules like fsevents, node-sass can be broken if you use different OS. You will be forced to only support a single platform(linux). 5. Impossible to resolve node_modules conflicts. Modern package manager have git conflict resolution build in. If two people update the same module to the same version they can still create a merge conflict when node_modules are checked. 6. Currently, you have plenty of good options that can achieve the same with smaller effort. You can use yarn2 with node_modules linker and local cache. This would create .yarn folder in the repo that have all modules as zip files. During install it would use these to hydrate node_modules. Alternatively, You can use pnp and have zero install but with proper support[3] 7. You lose automatic audit and dependency management. Current best practice is to use something like dependabot or renovate bot. Once you commit your package, you will no longer be able to use this effectively. 8. Most people commenting on left-pad are maybe not aware, but today npm is immutable, and you simply cannot unpublish public package[4]. Because npm.com is such vital infrastructure, it unlikely that it would ever stop working. [1] https://docs.github.com/en/actions/advanced-guides/caching-dependencies-to-speed-up-workflows https://docs.github.com/en/actions/advanced-guides/caching-d... [2] https://circleci.com/docs/2.0/caching/ https://circleci.com/docs/2.0/caching/ [3] https://yarnpkg.com/features/pnp https://yarnpkg.com/features/pnp [4] https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish

tentacleuno 5y ago
> This is idiotic and could only be written by someone that have no idea about node package managements. Some of your points are valid, but the first sentence seems really hand-wavy and rude. > 1. Most of CI systems have better options for caching node modules[1][2]. When you check node_modules, you add fixed cost(increasing) for every commit. When you use CI caching you add fixed cost(static) to only small number of builds. I was wondering about this too[0], mostly because it's the setup I tended to gravitate towards for my projects. Gitlab CI and Travis can do this AFAIK, although I'm not sure how long the cache folders would be kept (especially on the Free tier). [0]: https://news.ycombinator.com/item?id=29529154 https://news.ycombinator.com/item?id=29529154
- Chyzwar 5y ago
  > Some of your points are valid, but the first sentence seems really hand-wavy and rude. Because people here are discussing this and entertaining this idea. This creates a level of legitimacy. After this article, there might be now countless teams transitioning to this crazy idea. Then two years later, people would continue to complain about node ecosystem because they were burned badly by projects maintained using this approach. The problem with today word is that everyone tries to be politically correct. Everyone wants to discuss things in a civilized way based on merit and logic. In many cases, we could avoid wasting time and energy by declaring things as they are. For example, If mainstream would call anti-vaxxer stupid, we would have now more people vaccinated There are more things that people spend large amount of time discussing when there are nothing to discuss. This thread should not have 195 comments.
bennyp101 5y ago
"Because npm.com is such vital infrastructure, it unlikely that it would ever stop working." Except that is has? It's a service, like everything else on the internet, it can and will go down. The choice here is whether you can carry on, or wait until it comes back up. THAT is the main benefit I see in this. (Not everybody wants to manage a local copy/proxy/internal NPM registry etc)
- Chyzwar 5y ago
  We have limited amount of time, adopting this idea would impact productivity of team for long term. Making your application multi-region with backups and security is more important than protecting against a black swan event that would have limited impact. Even if npm goes down, you might have at maximum few hours of disruption for deploying in CI. This is relatively minor compared to recent us-east outage.

tentacleuno 5y ago

> This is idiotic and could only be written by someone that have no idea about node package managements. Some of your points are valid, but the first sentence seems really hand-wavy and rude. > 1. Most of CI systems have better options for caching node modules[1][2]. When you check node_modules, you add fixed cost(increasing) for every commit. When you use CI caching you add fixed cost(static) to only small number of builds. I was wondering about this too[0], mostly because it's the setup I tended to gravitate towards for my projects. Gitlab CI and Travis can do this AFAIK, although I'm not sure how long the cache folders would be kept (especially on the Free tier). [0]: https://news.ycombinator.com/item?id=29529154 https://news.ycombinator.com/item?id=29529154

Chyzwar 5y ago
> Some of your points are valid, but the first sentence seems really hand-wavy and rude. Because people here are discussing this and entertaining this idea. This creates a level of legitimacy. After this article, there might be now countless teams transitioning to this crazy idea. Then two years later, people would continue to complain about node ecosystem because they were burned badly by projects maintained using this approach. The problem with today word is that everyone tries to be politically correct. Everyone wants to discuss things in a civilized way based on merit and logic. In many cases, we could avoid wasting time and energy by declaring things as they are. For example, If mainstream would call anti-vaxxer stupid, we would have now more people vaccinated There are more things that people spend large amount of time discussing when there are nothing to discuss. This thread should not have 195 comments.

bennyp101 5y ago

"Because npm.com is such vital infrastructure, it unlikely that it would ever stop working." Except that is has? It's a service, like everything else on the internet, it can and will go down. The choice here is whether you can carry on, or wait until it comes back up. THAT is the main benefit I see in this. (Not everybody wants to manage a local copy/proxy/internal NPM registry etc)

Chyzwar 5y ago
We have limited amount of time, adopting this idea would impact productivity of team for long term. Making your application multi-region with backups and security is more important than protecting against a black swan event that would have limited impact. Even if npm goes down, you might have at maximum few hours of disruption for deploying in CI. This is relatively minor compared to recent us-east outage.