Node.js Loaders Team Meeting 2024-08-27 #222

Activity

1. mhdawson

   self-assigned this

   on Aug 23, 2024
2. joyeecheung commented on Aug 23, 2024

   

   joyeecheung

   on Aug 23, 2024

   Member

   More actions

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

   👍React with 👍1Reacted by Raz Luvaton
3. rluvaton commented on Aug 24, 2024

   

   rluvaton

   on Aug 24, 2024

   Member

   More actions

   I will join
4. joyeecheung commented on Aug 27, 2024

   

   joyeecheung

   on Aug 27, 2024

   Last edited by joyeecheung

   Member

   More actions

   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.
5. joyeecheung

   closed this as completedon Sep 30, 2024
6. github-staff

   deleted a comment from on Sep 3, 2025