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.

[hemanth]

There is all-builtins as well.

[Trott]

@hemanth That looks like it lists all the modules that are automatically loaded by the REPL, but not all the built-ins available in Node. It misses console, constants, module, process, repl, timers and the deprecated modules sys and freelist.

[hemanth]

@Trott Right, we need to work on process.binding('natives') then.

[ChALkeR]

@hemanth No, we need to deprecate process.binding('natives') and provide just the list instead.

[hemanth]

@ChALkeR That's the best thing to happen, but in the current situation.

[vkurchatkin]

Here is a simple way to check if module is built-in using only public APIs:

function isBuiltin(module) {
  try {
     const resolved = require.resolve(module);
     return !resolved.includes(require('path').sep);
   } catch(e) {
     return false;
   }
}

[piranna]

That's genious :-) Good trick! :-D
El 18/2/2016 15:01, "Vladimir Kurchatkin" notifications@github.com
escribió:

Here is a simple way to check if module is built-in using only public APIs:

function isBuiltin(module) {
try {
const resolved = require.resolve(module);
return !resolved.includes(require('path').sep);
} catch(e) {
return false;
}
}

—
Reply to this email directly or view it on GitHub
#3307 (comment).

[hemanth]

@vkurchatkin @piranna is-builtin

[vkurchatkin]

closing, doable using existing APIs

[Fishrock123]

Reopening from #6207 (comment)

[ChALkeR]

@vkurchatkin

closing, doable using existing APIs

That is not accurate. That API does exist, but it's not documented, and is-builtin uses an undocumented _-prefixed property.
See https://github.com/hemanth/node-is-builtin/blob/master/index.js.

Perhaps we should just expose that exact property and document it?