Node.js Loaders Team Meeting 2023-09-26

[mhdawson]

Time

UTC Tue 26-Sep-2023 18:00 (06:00 PM):

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

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Loaders%20Team+Meeting+2023-09-26&iso=20230926T1800
• or https://www.wolframalpha.com/input/?i=06PM+UTC%2C+Sep+26%2C+2023+in+local+time

Links

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

Agenda

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

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

[JakobJingleheimer]

@GeoffreyBooth in a chat we had a few days ago, you mentioned what I think is a material objection to a fundamental piece (a file extension map) of nodejs/node#49704. Should we discuss that here? I'd like to understand the root of your concern, and how it might be addressed, because I think what Antoine and I have roughed out is essential to this feature.

RE pointing to a guide, I think that's okay for v0.5 but doesn't fit the bill for a final feature (everyone having to look something up does not seem "first class", which is the mandate of the feature).

[GeoffreyBooth]

I don't have any objections to that PR beyond the comments I left on it. Do you have plans for a registry beyond what I see in the PR? We can discuss tomorrow.

[JakobJingleheimer]

Oh! Then great 🙂

I think a dual approach would be ideal—local and remote. Antoine's point that node does not make any requests on its own is a strong argument against node specifically fetching that; if we can fetch it some other way (eg npm search), I think that would be best. If there's no automated way, perhaps next-best is to print a message pointing to a guide, wherein the user can download (or copy+paste into a file) some kind of config for node to consume.

A key step (as far as I see it) is the loader getting automatically written into some config (eg .env) that node will henceforth consume.

Otherwise, this does little more than a blog post, which already exist today.

[GeoffreyBooth]

We can chat tomorrow if you and @aduh95 are available. I think we at least need a page in https://nodejs.org/en/docs/guides spelling out what people should do. I would start with that, get something really solid written there, because whatever steps we recommend in that would be what we would try to automate with a script.

Then the error message can both link to that guide and provide a command to run like npx @nodejs/add-typescript that would run something from npm that would prompt the user into enabling TypeScript support per whatever method we recommend in the guide; maybe it’s a wizard that presents a variety of options, etc. Having it be an npx script means that we avoid the problem of Node making network calls; and we aren’t tied to Node version, so it can be updated over time separately from Node. And then we can make the script as elaborate as we want; it can integrate with --env-file, etc. If and when we support a Node config file via JSON instead of .env, we can update the script to use that instead. And so on.

I think this is all we need. The only “registry” would be something within Node core that triggers appropriate error messages, like the TypeScript extensions prompting the TypeScript-specific message, as you have in that PR. I think that’s fine. What I was concerned about was some kind of registry that would be user configuration, akin to require.extensions, since our current ways of registering loaders don’t map cleanly to a file extension-based approach.

[JakobJingleheimer]

Cool. Works for me 🙂

I'm available. Sounds like maybe we don't need to meet after all now though?

[GeoffreyBooth]

Either way is fine by me, just let me know.

[JakobJingleheimer]

Let's skip 🙂