To be or not to be in core
This document explains things to consider when deciding whether a component should be in core or not.
A component may be included in core as a dependency, a module, or integrated into the code base. The same arguments for including/not including in core generally apply in all of these cases.
Strong arguments for including a component in core
- The component provides functionality that is standardized (such as a Web API) and overlaps with existing functionality.
- The component can only be implemented in core.
- The component can only be implemented in a performant way in core.
- Developer experience is significantly improved if the component is in core.
- The component provides functionality that can be expected to solve at least one common use case Node.js users face.
- The component requires native bindings. Inclusion in core enables utility across operating systems and architectures without requiring users to have a native compilation toolchain.
- Part or all of the component will also be re-used or duplicated in core.
Strong arguments against including a component in core
- None of the arguments listed in the previous section apply.
- The component has a license that prohibits Node.js from including it in core without also changing its own license.
- There is already similar functionality in core and adding the component will provide a second API to do the same thing.
- A component (or/and the standard it is based on) is deprecated and there is a non-deprecated alternative.
- The component is evolving quickly and inclusion in core will require frequent API changes.
Benefits and challenges
When it is unclear whether a component should be included in core, it might be helpful to consider these additional factors.
Benefits
- The component will receive more frequent testing with Node.js CI and CITGM.
- The component will be integrated into the LTS workflow.
- Documentation will be integrated with core.
- There is no dependency on npm.
Challenges
- Inclusion in core, rather than as an ecosystem module, is likely to reduce code merging velocity. The Node.js process for code review and merging is more time-consuming than that of most separate modules.
- By being bound to the Node.js release cycle, it is harder and slower to publish patches.
- Less flexibility for users. They can't update the component when they choose without also updating Node.js.