Repository navigation
Publish native modules independently. #2729
Description
Activity
Typically this is handled by explicitly specifying
enginesin yourpackage.jsonand/or branching onprocess.versionwhen you need to smooth over differences between major node.js/io.js versions that you're supporting for a particular (major) version of your project/module.Version-checking in your code will be the most robust for backwards-compat. Otherwise, to send warnings, use the
enginesfield.Another option if you really need to maintain versions against node major releases, would be:
module-node.version.numbersIf a package is usually used as a dependency
enginesis not really helpful. I can't tell don't depend on it if you're running a different version of node. Usingprocess.versionworks but it requires unnecessary work on my side. The newurlmodule in iojs has a bug fix inresolvemethod. I wish I could use the new and fixedurlmodule in all engines.On Tuesday, September 8, 2015, Brian White notifications@github.com wrote:
@mohsen1 https://github.com/mohsen1 Why not just extract url.js from
here and use it in your project then?+1 for your idea @mohsen1. The Cordova project did this starting with 3.0.
Sent from my mobile
I can't tell don't depend on it if you're running a different version of node.
Why not? Surely you don't expect people to use your module with e.g. Node.js 0.4? That's why READMEs usually mention which Node.js versions are supported.
Closing since no discussion since october last year
Can you publish and maintain latest iojs native modules in npm? If we want to support all active versions of Node then we can't simply
require(<native module>)since it has different behaviors in different versions of Node.For example, breaking changes in
urlmodule caused an issue for our test here. So now it's not safe to requireurlmodule anymore since you don't know what you are going to get back.