Migration of core modules to primordials

[targos]

This is a tracking issue for the migration of core modules to use builtins from the primordials object.

At the moment, for performance-sensitive code, only static methods and global functions should be migrated. V8 8.0 might have the optimization that we need to migrate prototype methods.

[ljharb]

I would love to, but unfortunately that time conflicts with childcare duties. I could potentially call in towards the later part of that hour - after 11:40AM EDT or so - if the meeting goes that long. Is that an option?

[gireeshpunathil]

thanks @ljharb . Ideally the meeting runs for an hour, so it is technically possible to adjust the agenda to meet this need. Also I don't think the pitch needs all the three proponents to be available at the same time. I will work with the chair to accommodate this. thanks!

[gireeshpunathil]

@ljharb (@bmeck , @BridgeAR) - correction to my previous comment, the TSC sitting is happening on 6th, not on 7th. Does it make things better or worse for you?

[ljharb]

Typically i'd have that whole hour free, but this particular Wednesday I also do childcare, so I'll be able to call in the last 20-15 minutes of that hour (any time between ~11:45AM ET - 12:30PM ET)

[bmeck]

This should be fine for me

[BridgeAR]

I can not guarantee to be able to participate tomorrow due to some work obligations.

[gireeshpunathil]

is there a link for non TSC members?

pls standby, I will let you know in few mins.

[gireeshpunathil]

just sent you the details over mail, pls check

[js-choi]

@gireeshpunathil: I’m the champion of the new bind-this operator proposal that is partially motivated by Node’s primordials use case, and which I will present to the next TC39 plenary. I’d like to listen in on the TSC meeting too, if that would be appropriate.

[aduh95]

It's being discussed right now, you can follow along on the public stream: https://www.youtube.com/c/nodejs+foundation/live

[Trott]

Per discussion at the TSC meeting today, we need more @nodejs/tsc folks to get involved in identifying all viable options (and eliminating options that are not viable).

[aduh95]

In a previous TSC meeting there was a question regarding if it was possible to use primordials only in internal modules related to ESM implementation. Here's the list of all the dependencies of the internal/modules/esm/* modules:

- async_hooks - buffer - crypto - events - fs - internal/abort_controller - internal/assert - internal/async_hooks - internal/blob - internal/bootstrap - internal/buffer - internal/cli_table - internal/console - internal/constants - internal/crypto - internal/encoding - internal/errors - internal/event_target - internal/fixed_queue - internal/fs - internal/heap_utils - internal/idna - internal/linkedlist - internal/modules - internal/options - internal/perf - internal/policy - internal/priority_queue - internal/process - internal/promise_hooks - internal/querystring - internal/readline - internal/source_map - internal/stream_base_commons - internal/streams - internal/timers - internal/tty - internal/url - internal/util - internal/validators - internal/vm - internal/webstreams - internal/worker - os - path - querystring - stream - string_decoder - timers - url - util - v8 - vm

So it's a long list, you can also check the visual dependecy graph if that helps.

[mcollina]

In fairness, I think the API footprint is significantly lower and some of those modules are not strictly used but pulled for other APIs.

[mhdawson]

Removed from TSC agenda as we tagged the issue in the TSC repo for the vote instead. That issue refers to this one.