Skip to content

Conversation

@SimenB
Copy link
Contributor

@SimenB SimenB commented Oct 22, 2017

It's not documented, but it's there to allow us to access the internal core node C++ bindings.

One common use case is doing process.bindings('fs').realpath to access the native realpath or process.bindings('natives') to get a list of all built-in modules in node.

(I understand if you don't want to add undocumented functions)

@vkurchatkin
Copy link
Contributor

but it's there to allow us to access the internal core node C++ bindings

Not really, it's there only for Node.js itself, i.e. it is not a part of public API. Using is causes a lot of problems.

@SimenB
Copy link
Contributor Author

SimenB commented Oct 22, 2017

I suppose if things like nodejs/node#15776 are done more often, the use-cases will disappear.

But with nodejs/node-v0.x-archive#624 closed, getting access to a list of built-in modules is a pain (https://github.com/tapjs/stack-utils/blob/459f196b67b01684f6d370ab774944de184a8cfe/index.js#L16-L28 & https://github.com/sindresorhus/builtin-modules/blob/32ab9f2fe30c1cad2b449d7e6058a1b4018d9b88/index.js#L8-L10).

I can agree on them being edge-cases though, and not wanting to make it easier to use/discover process.binding than it is

@SimenB
Copy link
Contributor Author

SimenB commented Dec 18, 2017

Meh, bad practice

@SimenB SimenB closed this Dec 18, 2017
@SimenB SimenB deleted the process-binding branch December 18, 2017 12:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants