To be or not to be in core

[ronag]

The discussion regarding whether or not s module should be in core seems to pop every now and then and I feel it's a little unfortunate that it kind of always has to start over from almost nothing and with different people involved.

Whether something should be or shouldn't be in core is quite complicated and it will be difficult to agree on any consistent set of rules for this that an be applied across the board. However, I think we should still be able to write up something in terms of what things we consider, what is advantages and disadvantaged to either approach etc. So that when these discussions pop up we have some form of summarized and organized prior knowledge/discussion/thoughts document to refer to.

I think it would maybe be appropriate for the TSC to provide some form of guideline here.

Some examples where it's unclear whether things should be in core or not:

• mime util: add MIME utilities node#21128
• stream.pipeline, stream.finished, stream.pipelinify
• undici Future of the Node HTTP Client  node#38533
• ws Adding Websocket support to core node#19308
• form data Adding HTML form data handling to core node#38943
• streams https://github.com/nodejs/readable-stream

and probably more...

As I see it we have 3 possible approaches on a module by module basis:

1. include in core
2. include in some kind of "standard library" (e.g. npm @node/package-name).
3. external package which lives under the nodejs org in GitHub (e.g. undici)

Some initial notes from me to start from:

• Part of LTS workflow
• CITGM
• More "trust"
• Other core modules can use the functionality

• Same as 3 but maybe with more "trust"

• Higher development velocity.
• Higher publishing velocity. User can access fixes and new features quicker.
• More fine grained step by step upgrade by users in terms of breaking changes.

[targos]

• Ability to create standalone scripts that take advantage of the feature without the need of npm/package.json/dependencies

[ronag]

I think there is also:

4. develop inside core and publish to npm (readable-streams)
5. Develop outside of core and sync it in every now and then (llhttp)

[Trott]

@nodejs/tsc

[ronag]

The undici discussion got a little heated nodejs/node#39057 which is also a reason it would be nice to be able to provide a bit more context I. Those discussions.

[ronag]

@jasnell also had a nice write up on Twitter https://twitter.com/jasnell/status/1405682071440297986?s=21

[mhdawson]

For

Simplified build/better cross platform testing if native code is required
Good performance can sometimes only be achieved through integration in core.

[tniessen]

Also:

1. include in core

• consistent API (e.g., http ~ https ~ http2)

3. external package which lives under the nodejs org in GitHub (e.g. undici)

• allows APIs that aren't consistent with Node.js core conventions

[Trott]

This was discussed briefly in TSC. Worth documenting. Needs more input from other @nodejs/tsc folks. Please review and comment!

[bmeck]

I wasn't there, but I would add that various efforts to be robust (mainly coding styles and primordials) are not really able to be enforced easily. To do so you have to do things like I did with MIME being able to be in a different repo : https://github.com/bmeck/node-internals-mime . I think having consistent patterns to avoid various concerns of cross module workflows gets complicated if we fracture into many different repositories but don't have any guidelines for those repositories.

[mmarchini]

During today's TSC meeting it was suggested that we have a separate meeting with folks interested in this issue. Would folks be interested in that, and if so does anyone volunteer to coordinate the meeting?