3 ms·

I used to not have issues with Java or .net, but with npm it’s very painful; I need to pin everything as updates, even minor ones, break whole slews of things.

I used to not have issues with Java or .net, but with npm it’s very painful; I need to pin everything as updates, even minor ones, break whole slews of things. And that’s with dependencies of dependencies of dependencies. If you are not a consulting outfit (I suspect consultancy outfits love the js ecosystem; every day something breaks so that’s another few $150/hr hours), but have a company with 100+ applications installed that actively make or help you make your bottom line, you want them to run in peace for years or decades. If no new features or security issues arrive, you don’t want to spend $0.01 on them as what’s the point of that? And that’s where this new fangled crap falls down: we have Django and .net apps running that are 10 years old, php and java ones 15-20 years old that all survived without much or any work. We have apps in js/typescript from 1 year ago that have bucketloads of deprecated, no longer supported, mandatory update warnings. It’s a pita so we are looking to move back to php or/and Django. I can see that in a startup with a dedicated team, this would be no issue; you are on top of all and working daily. Note as well that for some products (the more regulated of our products; financial/health/gov) have strict dependencies we all have to vet; in our experience of the past 4 years, it’s not a hallucination that npms change so often without any useful new features or fixes; just some useless dep updates that sometimes break things and weren’t needed, at all (you do not always need the latest version of everything ya know); I suspect (but maybe someone here knows) is that npms often update because it gives the authors more kudos somehow (as in; if posting many videos on TikTok ups your engagement; does that work for npm updates and new useless npms too?).

holoduke 3y ago
What are really painful if i may ask? We have some very old node express servers running. I think 20 years old. They still work after so many years. Occasionally I update them. But never really run into issues. For those old php/puthon projects. Do you really have package manager used for those? Most of those old projects are just folders with scripts without any managers.
- curtisblaine 3y ago
  It's painful when you have a lot of peer dependencies in your tree and then you are forced to update one dependency for security reasons. That dependency may have updated peer dependencies that are not compatible with the existing ones, which forces you to upgrade other dependencies and so on, in a domino effect. If the dependencies you have upgraded to are not compatible with your code or, worse, you configuration, you might end up refactoring big chunks of your application. This happens a lot with the frontend ecosystem (where everything is a peer dependency of either react or webpack / rollup / whatever build system) but can happen on the backend too (where many things are plugins / middlewares of express or whatever server you're using and carry a peer dependency on express). This is made more evident by the fact that, in its latest iterations, the npm project decided to install peer dependencies by default and break if their collective ranges are not compatible (before it just warned), essentially breaking CI if peer deps are broken (I'm not saying it's a bad move, before that a lot of applications essentially failed less but more obscurely). Another issue is the fact that the Node project moves quite fastly and new versions of dependencies that you must support for security reasons may be dependant on newer Node engines. A simple dependency migration, in that case, might become a migration towards a new version of Node, that 1) in corporate environments might not be available 2) might clash with other dependencies being still dependent on earlier versions of the Node engine 3) might deprecate or remove some of the APIs you were using. All this makes sense per se: upgrading dependencies is a complex topic that shouldn't be taken lightly. What makes less sense, imho, is the extreme customizability of a Node project: millions of available small dependencies that you can combine however you like, fractally (your deps do this as well, and their deps and so on). The ecosystem would probably benefit from more monolithic dependencies that are less customizable. Rome was a project in this sense - a monolithic package of pre-configured, opinionated dev tooling - but now the cat is out of the bag. Less experienced developers will bikeshed if they can and npm is the perfect ecosystem to bikeshed your way to thousands of dependencies that are not upgraded regularly and after a couple of years become a nightmare to upgrade in bloc. That's why people are starting to write zero-deps code.
- nanidin 3y ago
  Node was released in 2009 :)

holoduke 3y ago

What are really painful if i may ask? We have some very old node express servers running. I think 20 years old. They still work after so many years. Occasionally I update them. But never really run into issues. For those old php/puthon projects. Do you really have package manager used for those? Most of those old projects are just folders with scripts without any managers.

curtisblaine 3y ago
It's painful when you have a lot of peer dependencies in your tree and then you are forced to update one dependency for security reasons. That dependency may have updated peer dependencies that are not compatible with the existing ones, which forces you to upgrade other dependencies and so on, in a domino effect. If the dependencies you have upgraded to are not compatible with your code or, worse, you configuration, you might end up refactoring big chunks of your application. This happens a lot with the frontend ecosystem (where everything is a peer dependency of either react or webpack / rollup / whatever build system) but can happen on the backend too (where many things are plugins / middlewares of express or whatever server you're using and carry a peer dependency on express). This is made more evident by the fact that, in its latest iterations, the npm project decided to install peer dependencies by default and break if their collective ranges are not compatible (before it just warned), essentially breaking CI if peer deps are broken (I'm not saying it's a bad move, before that a lot of applications essentially failed less but more obscurely). Another issue is the fact that the Node project moves quite fastly and new versions of dependencies that you must support for security reasons may be dependant on newer Node engines. A simple dependency migration, in that case, might become a migration towards a new version of Node, that 1) in corporate environments might not be available 2) might clash with other dependencies being still dependent on earlier versions of the Node engine 3) might deprecate or remove some of the APIs you were using. All this makes sense per se: upgrading dependencies is a complex topic that shouldn't be taken lightly. What makes less sense, imho, is the extreme customizability of a Node project: millions of available small dependencies that you can combine however you like, fractally (your deps do this as well, and their deps and so on). The ecosystem would probably benefit from more monolithic dependencies that are less customizable. Rome was a project in this sense - a monolithic package of pre-configured, opinionated dev tooling - but now the cat is out of the bag. Less experienced developers will bikeshed if they can and npm is the perfect ecosystem to bikeshed your way to thousands of dependencies that are not upgraded regularly and after a couple of years become a nightmare to upgrade in bloc. That's why people are starting to write zero-deps code.
nanidin 3y ago
Node was released in 2009 :)