bindings: adding process.binding('builtins') method

[thlorenz]

• this method traverses the modlist_builtin linked list and returns an
  object which has binding names as keys and their versions as values

Sample Output:

➝  ./node
> process.binding('builtins')
{ tls_wrap: 44,
  crypto: 44,
  uv: 44,
  udp_wrap: 44,
  process_wrap: 44,
  tty_wrap: 44,
  timer_wrap: 44,
  tcp_wrap: 44,
  stream_wrap: 44,
  spawn_sync: 44,
  smalloc: 44,
  signal_wrap: 44,
  pipe_wrap: 44,
  zlib: 44,
  v8: 44,
  os: 44,
  http_parser: 44,
  fs: 44,
  contextify: 44,
  buffer: 44,
  js_stream: 44,
  cares_wrap: 44,
  fs_event_wrap: 44,
  async_wrap: 44 }

This is in a sense the binding counter part to process.binding('natives'), except for bindings and the fact that it doesn't include any sources.

[trevnorris]

All of these will always have the same version. It might make more sense to do something like

{  version: 44,
   bindings: [<list>]
}

/cc @bnoordhuis
Am I correct in that assumption?

[thlorenz]

I wasn't sure about the meaning of the versions, but I figured they could be different (why else would each binding have one).
I could change this to an array or include a bindings hash which adds different values, i.e. file_path.
Not sure if that information would be useful though.

If we return a bindings array we may also exclude the version info all together, i.e. just return an Array instead of an Object. Again I'm not sure of the importance/significance of the version field.

[trevnorris]

@thlorenz The version is the same as defined as NODE_MODULE_VERSION in src/node_versions.h.

Since developers can get the module version as process.versions.modules I'd say just make an array and leave out other information.

[thlorenz]

Sounds good, will update the PR tomorrow.

[vkurchatkin]

@thlorenz may I ask, what is it for? process.binding is private so it doesn't expose any new functionality to the users

[thlorenz]

@vkurchatkin this is just to get a list of builtin bindings in case you need to know that information.
However you can only read that list (of strings), but not access the bindings or their source.
So it doesn't expose any functionality per se.

[thlorenz]

@trevnorris

I'd say just make an array and leave out other information.

Realized that the exports defined here is always an Local<Object>.
So trying to return a Local<Array> just for this special case seems inconsistent and would make that one extra code path very different from all other else if paths since we couldn't use this value return.

So for sake of consistency and simplicity I'll create an object instead with bindings property like you suggested before (except without the version as that is easily retrieved via process.versions.modules).
Returning an object has the added benefit that we could add more information via extra properties later without breaking backwards compatibility.

[thlorenz]

Adapted the implementation to return the following:

➝  ./node
> process.binding('builtins')
{ bindings:
   [ 'tls_wrap',
     'crypto',
     'uv',
     'udp_wrap',
     'process_wrap',
     'tty_wrap',
     'timer_wrap',
     'tcp_wrap',
     'stream_wrap',
     'spawn_sync',
     'smalloc',
     'signal_wrap',
     'pipe_wrap',
     'zlib',
     'v8',
     'os',
     'http_parser',
     'fs',
     'contextify',
     'buffer',
     'js_stream',
     'cares_wrap',
     'fs_event_wrap',
     'async_wrap' ] }

[bnoordhuis]

I don't see the point. process.binding() is internal, the list of bindings can and will change over time, and core doesn't have a need for it in the first place.

[thlorenz]

@bnoordhuis

the list of bindings can and will change over time

That's exactly why it'd be useful if users could get a list of the bindings implemented in the version that they are using.

I understand that core itself may have no need for this feature, but this info is very useful for specific tooling (at least it is in my case) and I thought adding it would help others who need it as well.

[bmeck]

I know binding('natives') is used to fast path and prevent overriding natives, with the new loaded bindings wouldn't this make sense to do the same check but on bindings?

[thlorenz]

If adding this to process.binding is the problem would it be preferable to expose this information in another way?
Don't want to pollute process though, so not sure where else it could go.

[Qard]

Everything available through process.binding() is intended only for internal use. The API is not guaranteed to be stable.

Userland should not have any reason to be using bindings directly. If they do, they are almost certainly doing the wrong thing and should be making a PR or feature request to expose the thing they need properly.

[thlorenz]

I get all the arguments, but if a tool needs that info it'd be very useful to get it this way instead of hard coding it somewhere or traversing the src folder and guessing which of these are bindings.
There is actually a module out there (can't find it currently) that's just JSON files containing a list of core modules and bindings.
Basically I want to avoid having to resort to those methods via a simple change here.

However if no one else has that need I'm ok with closing this PR and get that info the hacky way :(

[vkurchatkin]

My primary concern is that adding something to bindings like this makes it look like this is actually supposed to be used. Making this public is also not an option, because having a public list of internal stuff doesn't make much sense

[Qard]

But why would a tool need that? I'm not seeing the use case. Do you have something in particular in mind?

(Not trying to discount the value, just saying that I'm not seeing what exactly the value is.)

[bmeck]

I for one like the ability of having check if something exists if I use process.binding (lets face it people do use it / it does not have an underscore). I am sure some APM out there is doing things with process bindings, but lack real world examples.

[jasnell]

@thlorenz ... is this still something you'd like to pursue?

[jasnell]

Closing due to lack of activity or response.