4 ms·

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. (th

by 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).
- deleted 11y ago
  [deleted]
tlrobinson 11y ago
By "npm" I assume the author meant "packages in npm", not npm itself.
- steveklabnik 11y ago
  Right, but packages _in_ npm are still managed by npm. If it were to change the package format between major versions, there could be problems. At least, that's how I read the OP.
  - mintplant 11y ago
    I read it as: how do authors publishing packages on npm maintain compatibility between multiple versions of node with breaking standard library changes?

by ag_dubs 11y ago

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).
deleted 11y ago
[deleted]

tlrobinson 11y ago

By "npm" I assume the author meant "packages in npm", not npm itself.

steveklabnik 11y ago
Right, but packages _in_ npm are still managed by npm. If it were to change the package format between major versions, there could be problems. At least, that's how I read the OP.
- mintplant 11y ago
  I read it as: how do authors publishing packages on npm maintain compatibility between multiple versions of node with breaking standard library changes?