Re: Node core modules as packages

[billinghamj]

First off - I apologize if this has already been discussed. After quite a bit of searching, I haven't been able to find anything.

It seems to me that a large portion of the core Node modules would be more appropriate as packages published on npm.

So I have two questions:

1. Why aren't the modules in node core pulled out into packages?
2. Would consideration be given to making this change in a future major version of Node?

Thanks.

[Trott]

I might be over-simplifying, but basically the probability of something that is currently in core being moved out of core depends on how much breakage there would be in existing npm modules. An example is assert. If Node.js were being built all over again, there probably wouldn't be an assertion testing library as a core module. Instead people would be encouraged to use userland assertion libraries. Unfortunately, assert (and probably every other documented API in core) is widely used in npm modules. So, they may be deprecated but are unlikely to be removed. It comes with being the runtime for an unimaginably large ecosystem. It's also why there tends to be reluctance to adding new API surface area if it's something that can be done in userland modules. Once it's in core, it becomes all but impossible to remove.

[jasnell]

Just a quick note: the best place for questions like this is http://github.com/nodejs/help :-)

[billinghamj]

@jasnell: This is not a help request. The intention was to open a design discussion about how core modules are versioned (or not, as the case may be...)

I believe this is particularly important now that Node is changing major versions so regularly, in theory making breaking changes each time.

[bnoordhuis]

Why aren't the modules in node core pulled out into packages?

Most core modules are developed in lock-step with the internal and frequently changing C++ bindings layer. I think I speak for all maintainers when I say there is no desire whatsoever to maintain backwards compatibility at that level.

Would consideration be given to making this change in a future major version of Node?

Unlikely, for the reason described above. It's technically possible for the few JS-only modules we have but that's of limited value and would increase the maintenance burden because we could then no longer move part of the logic to C++ if deemed beneficial.

If you still think it's a good idea, there is nothing stopping (generic) you from packaging up files in lib/ and publishing them. Everything is MIT-licensed.

[billinghamj]

Ultimately the versioning of Node is concerning to people like me who make and publish a lot of packages. Every time there is a new major version of Node (now seemingly very often), I have to go through all my packages worrying about whether there has been some API change which might cause me pain.

I think the key issue is that the major Node version changes often, but is almost always only a breaking change for native modules. There is no versioning or breaking change indication on a per-module basis.

As such, I have no idea whether the new major Node version is just a problem for native modules, or whether I need to go through all my pure-JS packages and figure out which core modules I have been using.

The engines section of the package.json file was presumably meant for this, but realistically doesn't actually help at all.

Perhaps some kind of per-module number which is incremented each time the API is broken.

[bnoordhuis]

There is no versioning or breaking change indication on a per-module basis.

Backwards incompatible changes currently are called out in the release notes. If you mean in the documentation, there is an open issue about that. You're welcome to help out.

[cjihrig]

Every time there is a new major version of Node (now seemingly very often)

Starting with v5, majors should only come once every 6 months.