61–70 of 132 posts
Earlier quoted context omitted.
Because if you don't, then a year or two down the road you're left with an unsupported legacy hell.
Node.js modules: from brand new to "unsupported legacy hell" in "a year or two." There's no way this is sustainable, but I'm at a loss of how to fix it, especially when the ECMAScript language itself is evolving at such a rapid pace. Any ideas?
So there seems to be folks complaining about how fast this release was and other folks saying it's not a big deal because 4.2.x is LTS. But I don't see anyone addressing the actual issue of breaking changes in node: npm. What does a module author do? If my module uses an API that was changed in 5.x, do I only support 4.2.x, do I only support 5.x or do I write in some hacks to try and check between the two? What if 6.…
'cause the actual changes that break between npm 1 and 2 are very small. (the changes to npm run, mostly, and the cache.) so it's Very Strange(tm) modules that break, and the new run behavior is much more useful
- npm team member
So there seems to be folks complaining about how fast this release was and other folks saying it's not a big deal because 4.2.x is LTS. But I don't see anyone addressing the actual issue of breaking changes in node: npm. What does a module author do? If my module uses an API that was changed in 5.x, do I only support 4.2.x, do I only support 5.x or do I write in some hacks to try and check between the two? What if 6.…
How is this different form any other package tool? PIP authors have python2/3, Julia pkg, ubuntu apt-get, ect. What's special about working with npm?
First, JavaScript lacks a standard library that can interact with a system so node.js is essentially the defacto extension of the JavaScript language to work with a system. If you had a change where its standard libraries change every 6 months (plus or minus a few) it wouldn't be fun.
Second, npm supports specifying the engine but you need to be able to update all versions due to security concerns, etc. If it's iterating too quickly with breaking changes then people are going to have to keep a branch for every version and update each one when a security fix is required. That's not sustainable. Most people keep a LTS version and a bleeding edge version.
Python and other languages iterate but breaking changes in core APIs? Not very frequently.
Good lord people... 1. There is no one forcing you to upgrade, 4.2 is LTS, you've got 2yrs+ 2. 5.0 followed 4.0 so closely because 4.0 was the iojs/node merge and 5.0 was to correspond with the new V8 release, future major bumps will be closer to 6mo (to match V8)
Earlier quoted context omitted.
Because if you don't, then a year or two down the road you're left with an unsupported legacy hell.
Node.js modules: from brand new to "unsupported legacy hell" in "a year or two." There's no way this is sustainable, but I'm at a loss of how to fix it, especially when the ECMAScript language itself is evolving at such a rapid pace. Any ideas?
JS being relatively fashionable and easy to write, it attracts all the younger devs that can't be bothered with backwards compatibility, stability, etc, and keep changing, restructuring etc their projects as they go along.
There are exceptions of course, e.g. anything by jashkenas, but this breakage happens a lot. Also with people adopting the latest shiny new framework every year or so (e.g. it feels like ages when Backbone was the shiny new thing, but it was merely 5 years ago -- since then we've had Ember, then Angular, then React take the spotlight).
So there seems to be folks complaining about how fast this release was and other folks saying it's not a big deal because 4.2.x is LTS. But I don't see anyone addressing the actual issue of breaking changes in node: npm. What does a module author do? If my module uses an API that was changed in 5.x, do I only support 4.2.x, do I only support 5.x or do I write in some hacks to try and check between the two? What if 6.…
hey! do you have a specific problem in mind or is this just a hypothetical musing? 'cause the actual changes that break between npm 1 and 2 are very small. (the changes to npm run, mostly, and the cache.) so it's Very Strange(tm) modules that break, and the new run behavior is much more useful - npm team member
It's not really anything against npm itself and if the node team doesn't do this with high frequency then it won't be an issue. The 5.x coming so soon after 4.x was just jarring and everyone is speculating how frequently they're going to make breaking changes.
Good lord people... 1. There is no one forcing you to upgrade, 4.2 is LTS, you've got 2yrs+ 2. 5.0 followed 4.0 so closely because 4.0 was the iojs/node merge and 5.0 was to correspond with the new V8 release, future major bumps will be closer to 6mo (to match V8)
Earlier quoted context omitted.
> 1. There is no one forcing you to upgrade, 4.2 is LTS, you've got 2yrs+ And in 2 years, when we take a peak we see that the changes amassed in between by the non LTS releases are so big we have to pretty much rewrite all of our codebase if we want to continue getting support....
i have an app that was written for 0.8 three years ago. it is running on 4.2 with no modification. (it doesn't use any binary add ons). javascript is almost entirely backwards compatible because they can't break the web. Other apps that require binary add ons required me to install the latest versions from NPM -- one one of them required ANY changes to how the API was called and it was extremely minor. Waiting 2 year…