Expose up-to-date list of builtin modules

[zkat]

npm's normalize-package-data needs a list of built in node modules in order to warn against potential package name conflicts (see fixNameField.

We used to have the list hardcoded, and then @sindresorhus was kind enough to author an external package that would maintain such a list, is-builtin-module.

It seems that this list is best maintained by node itself, since there's always a risk of things going out of sync or being just plain wrong. Would it be possible to expose this directly through some built-in value in node?

Ref: https://github.com/nodejs/node/pull/3299/files#r41686776

cc @Fishrock123

[Fishrock123]

Fwiw is-builtin-module uses the builtin-modules module, whose source code is as follows:

'use strict';

var blacklist = [
    'freelist',
    'sys'
];

module.exports = Object.keys(process.binding('natives')).filter(function (el) {
    return !/^_|^internal/.test(el) && blacklist.indexOf(el) === -1;
}).sort();

Specifically, this bit: Object.keys(process.binding('natives')) will stop working in the future.

See:

• src: log warning on process.binding('natives'): src: log warning on process.binding('natives') #2741 (LANDED)
• node: deprecate public access to process.binding: node: deprecate public access to process.binding #2768 (discussion)

About the first, process.binding('natives') returns data (the whole damn source code) which cannot be guaranteed not to change. As such we're going to be moving away from it pretty much asap.

[Fishrock123]

I suggest we have an API that exposes a list of core module names only.

[piranna]

On NodeOS we were thinking about moving out all build-in modules to reduce the size of the binary and it's memory foot print, I think this could be really useful...

[sindresorhus]

👍 As illustrated, doing this in user-land is brittle.

[ChALkeR]

See also: #3078 (comment) and ayecue/node-cjs-deps@b3ea440.

We might want to provide a way to expose a list of _prefixed (but not internal) module names.
For example, require('module').builtinModules for the normal list and require('module')._builtinModules for the full list that includes both normal and _prefixed builtin module names.

And yes, names only.

Note: per doc, this should not be put into the module module, it's Frozen. We need a different place I guess.

[ChALkeR]

cc @Trott

[trevnorris]

Ref: #2180

NM. Different list.

[Fishrock123]

@trevnorris that's not quite the same though, is it?

Also, should it list internal modules too, or should that be something separate?

I've noticed some things, such as debuggers, apparently rely on knowing what internal modules there are, which is weird. I'd prefer someone to give a solid reason why first.

[sindresorhus]

Also, should it list internal modules too, or should that be something separate?

Only public modules. If there's a need for a list of internal modules, it should be a separate thing.

[ChALkeR]

@Fishrock123 Internal or prefixed? Could you give an example, please?

[Fishrock123]

Only public modules. If there's a need for a list of internal modules, it should be a separate thing.

Makes sense, I was thinking along these lines too.

@ChALkeR I meant /internal/. Prefixed modules would appear in the regular one as they are potential module name conflicts.