Node.js Loaders Team Meeting 2024-08-27

[mhdawson]

Time

UTC Tue 27-Aug-2024 18:00 (06:00 PM):

Timezone	Date/Time
US / Pacific	Tue 27-Aug-2024 11:00 (11:00 AM)
US / Mountain	Tue 27-Aug-2024 12:00 (12:00 PM)
US / Central	Tue 27-Aug-2024 13:00 (01:00 PM)
US / Eastern	Tue 27-Aug-2024 14:00 (02:00 PM)
EU / Western	Tue 27-Aug-2024 19:00 (07:00 PM)
EU / Central	Tue 27-Aug-2024 20:00 (08:00 PM)
EU / Eastern	Tue 27-Aug-2024 21:00 (09:00 PM)
Moscow	Tue 27-Aug-2024 21:00 (09:00 PM)
Chennai	Tue 27-Aug-2024 23:30 (11:30 PM)
Hangzhou	Wed 28-Aug-2024 02:00 (02:00 AM)
Tokyo	Wed 28-Aug-2024 03:00 (03:00 AM)
Sydney	Wed 28-Aug-2024 04:00 (04:00 AM)

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Loaders%20Team+Meeting+2024-08-27&iso=20240827T1800
• or https://www.wolframalpha.com/input/?i=06PM+UTC%2C+Aug+27%2C+2024+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1f3lwmlwjjXKNb3ZcblanuIx4_G9E8yKQCWKLnJVM7TQ/edit

Agenda

Extracted from loaders-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

• Support .noderc or similar file-based initialization configurations? #53787
• Proposal for a simple, universal module loader hooks API to replace require() monkey-patching #52219
• ESM Hook deadlocks since 21.2.0 a3e09b3 #50948

nodejs/loaders

• Proposal: Moving hooks on thread #205
• Hooks thread direction #201
• doc: add synchronous hooks proposal #198

Invited

• Loaders team: @nodejs/loaders

Observers/Guests

Notes

The agenda comes from issues labelled with loaders-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/97506450082

• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live

[joyeecheung]

In openjs-foundation/summit#419 (comment) @rluvaton suggested to use this call to discuss nodejs/node#53787

[rluvaton]

I will join

[joyeecheung]

We weren't able to figure out YouTube access in time, so recorded it again on the Zoom cloud: zoom cloud recording link

Summary for the noderc discussion:

• We can start with version 0, which means the initial schema could be very unstable, but at least we can experiment with something landed and iterate on it. When it gets stable enough we can mark the version as 1 and from then on, we can have a built-in parser that supports multiple versions in one Node.js binary, which can return a more stable representation of the configuration via a JS API for tools to consume
• Whether we should have node namespace in the noderc file: I am not sure if we have any conclusions, there are pros and cons:
  • pros: other tools can dump other stuff in noderc; Node.js compatible runtimes can also dump their configurations in noderc, and they get to share the auto-discovery provided by Node.js if they need some infra for parsing and applying additional configs that are meant to be discovered like noderc; Fewer parsing cost if we skip non-node sections/namespaces (although for the JS API we still have to parse everything anyway?).
  • cons: more indentation, the field is already namespaced as "noderc" in the package.json so it seems redundant, it can be unintuitive to say having Bun configs in a file called .noderc.json; This could be potentially solved via other means (other tools can have other rc fields in package.json, or other ways to hoist the namespace outside the noderc file).
• Some discussions about sections, not sure what's our conclusion
  • It can be a bit too Node.js-specific
  • Other initialization file formats proposed before e.g. INI, TOML also have the concept of sections, maybe it's not too Node.js specific.
  • We'll support JSON in the first iteration, there might be support for other formats via some kind of plugin mechanism in future iterations, but it's not a goal for the initial implementation. Just need to leave some room for additional format support.
• What should other tools e.g. IDE do to interpret/generate this file?
  • They'll need to use some Node.js API to parse it and serialize it. Users can specify compatible Node.js versions in the engines field in pacakge.json.
  • The interpretation is ultimately up to Node.js
• Discussions about CLI flags.
  • Some nested structure to save common prefix would be nice e.g. { "test": { "name-pattern": [...], "runner-concurrency": 0 } } instead of {"test-name-pattern": [...], "test-runner-concurrency": 0}
  • More complex structure can also allow specifying detailed behavior e.g. only being applied to the main thread. Via the flat flags it might be possible to implement with more e.g. -subsetting=value suffixes to existing flags, but won't look as nice
• What should we do if the configuration is not recognized by the version of Node.js interpreting it
  • Warn and ignore, or make it configuratble e.g. warn by default & can be turned off, or don't warn by default but can be turned on for validation
• How do we skip settings for e.g. skipping test flags for non test use cases?
  • Maybe pair that with the sections, configs in a section only get applied when a certain environment variable is matching the section name. So NODE_RC_SECTION=test selects to match [test] sections in the rc file. NODE_RC_SECTION=main skips it.
  • Additionally the on-disk config can be overridden by other CLI flags or env vars.
• Next step:
  • Open a PR to maybe the loaders repo or somewhere else, with a proper JSON schema, and we bikeshed names and discuss the actual schema
  • It would be great to include some example project folders in the proposal since we are talking about multi-file directory structures most of the times when we hypothesize use cases, and it's a bit hard to follow without some concrete directory structure
  • Start the implementation when we more or less finalize the initial schema.