6 ms·

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 a

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.x comes in, say, 6 months and also breaks another API. Now I have 3 hacks or I only support 4.2.x or 6.x. This is the first major version since the io.js and node.js merger so I'm not that concerned yet but if they continue this pace then I will be very concerned (just like I was concerned when npm was supporting io.js and node.js when they had differences in their APIs; it forces module developers to choose and limit their availability). I would like to see some path of deprecation for node.js APIs that take multiple major versions to get away from unless it's a major security risk. Edit: just to clarify my worry: I'm not worried yet. But, and this is a big but, ECMAScript doesn't include any standard libraries for interacting with systems, http, etc so node.js has kinda assumed the role of a standard, defacto library for JavaScript when dealing with a system on a level outside of a web browser. So if the breaking API changes are going to occur every year or faster, to me that's like a language's standard libraries changing every year or sooner. Yes it's kinda not fair as node.js is NOT a set of standard JavaScript libraries but that's the role it's essentially been given due to the lack of one in ECMAScript.

jessaustin 11y ago
ISTM one could keep developing for the old nodejs under the current major version, or even the current major version plus a few more major versions. Then simultaneously release under a different major version for the new nodejs. The "engines" option of package.json makes it possible to partition one's releases this way. This may end up deviating a bit from semver, but node and npm have long done that themselves. Ideally, of course, one could simply avoid using unstable portions of the API. That's not always possible, but it should be possible to isolate that instability in a module like "readable-stream". Actually I suspect that any time one is tempted to use the "engines" option, it's time to break that specific API use out into a separate module.
- lacker 11y ago
  Does "engines" actually make it possible to partition your releases? I thought by default the engines part of packages.json was ignored.
  - jessaustin 11y ago
    Whoops, you're right. I guess there must be good reasons for that default. Maybe there has to be some version-checking in the API-using code itself. That makes it an even better idea to isolate that shit in a separate module.
tdaltonc 11y ago
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?
- devy 11y ago
  Python community doesn't release new versions nearly as fast. Every major python version release, there is usually a PEP announcing the schedule new version release date far in advance for the community to prepare. To me, Node community just release new versions fast and furious. If the committers won't, then there are people who jump out and fork the project. Of course there are the other extreme of long release cycles like Debian but there are good reasons for that. IMMO, a mature large community of an open source project community should always take the package ecosystem into considering when introducing new versions or breaking changes. PS: I was pretty annoyed that one of the npm package I used a lot `aglio` is broken again on 5.0.0 after I filed a ticket for the compatibly issue with 4.2.1. This ticket has just been closed a few days ago and is only less than two weeks old! https://github.com/danielgtaylor/aglio/issues/183 https://github.com/danielgtaylor/aglio/issues/183
- BinaryIdiot 11y ago
  So like my comment said I'm not that concerned about it today but if they are going to make breaking changes every 6 months then I'm worried and for two reasons that kinda separate node / npm apart from other packaging systems. 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.
ag_dubs 11y ago
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
- BinaryIdiot 11y ago
  Like I mentioned in my comment I'm not worried yet but if the node team iterates at this pace with breaking changes than I worry as node is essentially the defacto standard library for JavaScript when interacting with a system (since the real EMCAScript standard lacks interacting with file systems, http, etc). How many languages do you know that have standard libraries that iterate breaking changes frequently? Probably almost none that are mainstream. 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.
- untog 11y ago
  Is there / could there be an option in package.json for which Node version you support? Like, v1.0.0 of my lib supports up to and including Node 4.2.1, but v2.0.0 requires Node 5? That way people would get a working version relatively seamlessly. I realise this makes the package.json Node-specific, which might be something you want to avoid. EDIT: to part-answer my own question, package.json has the "engines" field. Not sure if that means it automatically installs old versions in older versions of Node, though.
  - BinaryIdiot 11y ago
    This is still current as far as I know: http://www.marcusoft.net/2015/03/packagejson-and-engines-and-enginestrict.html http://www.marcusoft.net/2015/03/packagejson-and-engines-and... Basically, you get an error but it won't give you the proper version. If that has changed I'd love to know, however (it most certainly should install the latest version for your environment and give you a warning that it's not the latest. In my opinion anyway).
frik 11y ago
I dislike they jumped from 0.1x (and io.js) to 4 and a months later the realise v8 semver is 5 and jump to 5 - stupid. They could have though about version numbers last months, and choose 5. A bit more conservative version numbering would be great. Nodejs up to 0.1x was to slow, and now it's way to fast - a application runtime is not a browser. Mind the library compatibility - not every dev has time to test for 0.1x, 4.x and now 5.
- phpnode 11y ago
  Yes, it's important to conserve integers lest we run out
  - Alupis 11y ago
    He's talking about the speed of code-breaking changes... and now a fragmented install base (similar to the Android problem).
fapjacks 11y ago
There are still major libraries that haven't updated their engine requirements in package.json to reflect that "proper" Node.js is now above 4.x (versus 0.10.x or 0.12.x), for example. It is a little bit surprising to me that they are at 5.x already. You know, it's pretty funny that all the io.js people (myself included) were complaining about how glacial the pace was from Joyent, and now here we are, seeing some grumbling about how quick the pace has picked up. :)
jasnell 11y ago
For Node.js core APIs, there is a deprecation strategy that requires at least one major version cycle before anything can be removed, and even then the chances of things actually being removed are slim. We're trying to take a very cautious and conservative approach to breaking changes in core. Generally, if it works in v4, it should continue to work in v5, if it doesn't, that's a bug that should be reported and fixed. Changes in npm, on the other hand are a different story. Technically, npm is not part of Node core, it's a utility that we bundle with the core but it has it's own lifecycle, it's own process and it's own separate project. The "contract" between npm and node.js is still being worked out and this kind of feedback is extremely useful.
- BinaryIdiot 11y ago
  > For Node.js core APIs, there is a deprecation strategy that requires at least one major version cycle before anything can be removed Considering there was 52 days between one major version cycle that criteria isn't really useful; I'd expect a timeframe more than a version cycle. > Changes in npm, on the other hand are a different story. Technically, npm is not part of Node core, it's a utility that we bundle with the core but it has it's own lifecycle, it's own process and it's own separate project. The "contract" between npm and node.js is still being worked out and this kind of feedback is extremely useful. I really should have said the main issue is really just writing code with node and sharing it; node has essentially been given the responsibility of being a standard set of libraries for JavaScript on the server and having standard libraries change APIs, even minor, in less than 2 months is typically indicative of a language pre 1.0. But I'm hopeful you're right and things should continue working in most respects, it's just the edge cases that worry me. I don't want to spend a ton of time developing something that ends up simply not working in the very next version without a good path of providing my code that works with both.
jasnell 11y ago
To be clear, v4.2 is the stable dependable target that most users should be using as their target. Developers that want to track new development and new features and have more flexibility can move up to v5. Next year at around this time, v6 will become the new stable target. The actual number of breaking changes between v4 and v6 are likely to be quite small -- things that work in v4 should continue to work in v6 and beyond really. So the best advice I can give is: if you are developing modules for developers to use in their applications, you'll want to primarily target v4 for now but keep an eye on where v5 is going and use that as your beta channel for new development going forward.

jessaustin 11y ago

ISTM one could keep developing for the old nodejs under the current major version, or even the current major version plus a few more major versions. Then simultaneously release under a different major version for the new nodejs. The "engines" option of package.json makes it possible to partition one's releases this way. This may end up deviating a bit from semver, but node and npm have long done that themselves. Ideally, of course, one could simply avoid using unstable portions of the API. That's not always possible, but it should be possible to isolate that instability in a module like "readable-stream". Actually I suspect that any time one is tempted to use the "engines" option, it's time to break that specific API use out into a separate module.

lacker 11y ago
Does "engines" actually make it possible to partition your releases? I thought by default the engines part of packages.json was ignored.
- jessaustin 11y ago
  Whoops, you're right. I guess there must be good reasons for that default. Maybe there has to be some version-checking in the API-using code itself. That makes it an even better idea to isolate that shit in a separate module.

tdaltonc 11y ago

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?

devy 11y ago
Python community doesn't release new versions nearly as fast. Every major python version release, there is usually a PEP announcing the schedule new version release date far in advance for the community to prepare. To me, Node community just release new versions fast and furious. If the committers won't, then there are people who jump out and fork the project. Of course there are the other extreme of long release cycles like Debian but there are good reasons for that. IMMO, a mature large community of an open source project community should always take the package ecosystem into considering when introducing new versions or breaking changes. PS: I was pretty annoyed that one of the npm package I used a lot `aglio` is broken again on 5.0.0 after I filed a ticket for the compatibly issue with 4.2.1. This ticket has just been closed a few days ago and is only less than two weeks old! https://github.com/danielgtaylor/aglio/issues/183 https://github.com/danielgtaylor/aglio/issues/183
BinaryIdiot 11y ago
So like my comment said I'm not that concerned about it today but if they are going to make breaking changes every 6 months then I'm worried and for two reasons that kinda separate node / npm apart from other packaging systems. 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.

ag_dubs 11y ago

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

BinaryIdiot 11y ago
Like I mentioned in my comment I'm not worried yet but if the node team iterates at this pace with breaking changes than I worry as node is essentially the defacto standard library for JavaScript when interacting with a system (since the real EMCAScript standard lacks interacting with file systems, http, etc). How many languages do you know that have standard libraries that iterate breaking changes frequently? Probably almost none that are mainstream. 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.
untog 11y ago
Is there / could there be an option in package.json for which Node version you support? Like, v1.0.0 of my lib supports up to and including Node 4.2.1, but v2.0.0 requires Node 5? That way people would get a working version relatively seamlessly. I realise this makes the package.json Node-specific, which might be something you want to avoid. EDIT: to part-answer my own question, package.json has the "engines" field. Not sure if that means it automatically installs old versions in older versions of Node, though.
- BinaryIdiot 11y ago
  This is still current as far as I know: http://www.marcusoft.net/2015/03/packagejson-and-engines-and-enginestrict.html http://www.marcusoft.net/2015/03/packagejson-and-engines-and... Basically, you get an error but it won't give you the proper version. If that has changed I'd love to know, however (it most certainly should install the latest version for your environment and give you a warning that it's not the latest. In my opinion anyway).

frik 11y ago

I dislike they jumped from 0.1x (and io.js) to 4 and a months later the realise v8 semver is 5 and jump to 5 - stupid. They could have though about version numbers last months, and choose 5. A bit more conservative version numbering would be great. Nodejs up to 0.1x was to slow, and now it's way to fast - a application runtime is not a browser. Mind the library compatibility - not every dev has time to test for 0.1x, 4.x and now 5.

phpnode 11y ago
Yes, it's important to conserve integers lest we run out
- Alupis 11y ago
  He's talking about the speed of code-breaking changes... and now a fragmented install base (similar to the Android problem).

fapjacks 11y ago

There are still major libraries that haven't updated their engine requirements in package.json to reflect that "proper" Node.js is now above 4.x (versus 0.10.x or 0.12.x), for example. It is a little bit surprising to me that they are at 5.x already. You know, it's pretty funny that all the io.js people (myself included) were complaining about how glacial the pace was from Joyent, and now here we are, seeing some grumbling about how quick the pace has picked up. :)

jasnell 11y ago

For Node.js core APIs, there is a deprecation strategy that requires at least one major version cycle before anything can be removed, and even then the chances of things actually being removed are slim. We're trying to take a very cautious and conservative approach to breaking changes in core. Generally, if it works in v4, it should continue to work in v5, if it doesn't, that's a bug that should be reported and fixed. Changes in npm, on the other hand are a different story. Technically, npm is not part of Node core, it's a utility that we bundle with the core but it has it's own lifecycle, it's own process and it's own separate project. The "contract" between npm and node.js is still being worked out and this kind of feedback is extremely useful.

BinaryIdiot 11y ago
> For Node.js core APIs, there is a deprecation strategy that requires at least one major version cycle before anything can be removed Considering there was 52 days between one major version cycle that criteria isn't really useful; I'd expect a timeframe more than a version cycle. > Changes in npm, on the other hand are a different story. Technically, npm is not part of Node core, it's a utility that we bundle with the core but it has it's own lifecycle, it's own process and it's own separate project. The "contract" between npm and node.js is still being worked out and this kind of feedback is extremely useful. I really should have said the main issue is really just writing code with node and sharing it; node has essentially been given the responsibility of being a standard set of libraries for JavaScript on the server and having standard libraries change APIs, even minor, in less than 2 months is typically indicative of a language pre 1.0. But I'm hopeful you're right and things should continue working in most respects, it's just the edge cases that worry me. I don't want to spend a ton of time developing something that ends up simply not working in the very next version without a good path of providing my code that works with both.

jasnell 11y ago

To be clear, v4.2 is the stable dependable target that most users should be using as their target. Developers that want to track new development and new features and have more flexibility can move up to v5. Next year at around this time, v6 will become the new stable target. The actual number of breaking changes between v4 and v6 are likely to be quite small -- things that work in v4 should continue to work in v6 and beyond really. So the best advice I can give is: if you are developing modules for developers to use in their applications, you'll want to primarily target v4 for now but keep an eye on where v5 is going and use that as your beta channel for new development going forward.