Node.js Loaders Team Meeting 2023-08-15

[mhdawson]

Time

UTC Tue 15-Aug-2023 18:00 (06:00 PM):

Timezone	Date/Time
US / Pacific	Tue 15-Aug-2023 11:00 (11:00 AM)
US / Mountain	Tue 15-Aug-2023 12:00 (12:00 PM)
US / Central	Tue 15-Aug-2023 13:00 (01:00 PM)
US / Eastern	Tue 15-Aug-2023 14:00 (02:00 PM)
EU / Western	Tue 15-Aug-2023 19:00 (07:00 PM)
EU / Central	Tue 15-Aug-2023 20:00 (08:00 PM)
EU / Eastern	Tue 15-Aug-2023 21:00 (09:00 PM)
Moscow	Tue 15-Aug-2023 21:00 (09:00 PM)
Chennai	Tue 15-Aug-2023 23:30 (11:30 PM)
Hangzhou	Wed 16-Aug-2023 02:00 (02:00 AM)
Tokyo	Wed 16-Aug-2023 03:00 (03:00 AM)
Sydney	Wed 16-Aug-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-08-15&iso=20230815T1800
• or https://www.wolframalpha.com/input/?i=06PM+UTC%2C+Aug+15%2C+2023+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1nY6Z3ahsIGtAJ2jrpqozz9hJ4W7fboGA2XvnjGJJyKo/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

[GeoffreyBooth]

Anything to meet about?

I think once nodejs/node#47999 lands, we will have completed Milestone 2 other than a follow-up PR to go ahead and remove globalPreload. @izaakschroeder or anyone else, if you want to do such a PR now you’re welcome to; we can mark it as “don’t land” so that the current state gets released first and then only in the following release (or one after that) is globalPreload gone.

nodejs/node#48890 would implement the first item in Milestone 3 and is close to landing. Then there’s adding built-in import maps support, which would be a great feature to add but would be a significant effort; and most of the remaining ones are smaller in scope, mostly exposing public APIs for internal features. We’re definitely in the homestretch.

[JakobJingleheimer]

🙋‍♂️ I'll do the globalPreload removal PR 🙂

I'll put together a tech design for import-maps and share it ~next week.

[GeoffreyBooth]

Do we want to meet to discuss the issues raised in nodejs/node#49144 (comment)? What and how to document, when to release what, what should be in separate PRs versus not, etc.

[JakobJingleheimer]

Sure. Should be a quick meeting 🙂

[GeoffreyBooth]

I’ll put together a tech design for import-maps and share it ~next week.

I found this: https://github.com/node-loader/node-loader-import-maps, you could maybe use it as reference (or we could just port it into core if it looks like what we would want, cc @giltayar).

[aduh95]

What and how to document, when to release what, what should be in separate PRs versus not, etc.

Could this meeting be an email a bunch of PRs? It would probably be a better use of our collective time if each of us used that time slot to make a PR, and then we can fine tune during the code review.

[GeoffreyBooth]

Could this meeting be an email a bunch of PRs?

Well I think we need to figure out what those PRs should do, but maybe that can happen here. What do you think of this?

In nodejs/node#49144, removing globalPreload:

• Remove globalPreload itself and its section from the docs, and all references to globalPreload.

In a follow-up “update the docs” PR:

• Change the stability level for the overall Loaders API to Stability: 1.2 - Release candidate.
• Remove the various “This API is currently being redesigned and will still change.” warnings from the docs.
• Add a new “Enabling” section just after a shortened introduction to the Loaders API in https://nodejs.org/api/esm.html#loaders. This new section would mention only the preferred approach, using --import with register (and offering --import with a data: URL as a suggestion for loaders that have no main thread component, like --import 'data:text/javascript,import("node:module").then(({ register }) => register("my-loader.js"))).
• We update --loader / --experimental-loader to print a warning that its use is unsupported and that users should instead use --import and register, with an example of the user’s actual input reformatted as an --import data URL that runs register for that import.
• We remove all mentions of --loader and --experimental-loader from the docs, even in https://nodejs.org/api/cli.html. (I don’t think we normally document no-longer-around experimental flags?) For now we don’t change the behavior of the flag, other than the above-mentioned warning; it just becomes undocumented.

[aduh95]

• We remove all mentions of --loader and --experimental-loader from the docs, even in https://nodejs.org/api/cli.html. (I don’t think we normally document no-longer-around experimental flags?) For now we don’t change the behavior of the flag, other than the above-mentioned warning; it just becomes undocumented.

That's probably not going to get consensus. --loader is already undocumented, yet it doesn't change the fact that it's used in the wild. We should keep it in the docs, but with a notice that we think it's going to go away. Bear in mind that we might keep it around if the ecosystem decides it's a better API than register().

The rest of it sounds good, I don't think we (you?) should holding off on opening that PR, even if it has to stay in draft until globalPreload is removal has landed (assuming it's going to land).

[GeoffreyBooth]

That’s probably not going to get consensus. --loader is already undocumented, yet it doesn’t change the fact that it’s used in the wild. We should keep it in the docs, but with a notice that we think it’s going to go away. Bear in mind that we might keep it around if the ecosystem decides it’s a better API than register().

Well I think the docs only mention --experimental-loader, but there are levels of “keeping them in the docs.” Like we could preserve its entry in cli.md but remove any mention from esm.md. Since we already don’t document --loader I don’t think it’s that much of a stretch to limit or eliminate --experimental-loader.

[JakobJingleheimer]

Geoffrey's list of things above (#154 (comment)) sounds good to me, and I like the approach of removing --experimental-loader from all docs accept CLI, and print a warning (I think there's a special kind that can be easily silenced) when it's used. I might not say it's "unsupported", but perhaps that --import is recommended and maybe that --experimental-loader may go away (so it's not recommended); but that may artificially lead to less use of an otherwise popular feature.

[GeoffreyBooth]

Geoffrey’s list of things above (#154 (comment))

Implemented in nodejs/node#49261 and nodejs/node#49265.