Repository navigation
Node.js Loaders Team Meeting 2023-08-15 #154
Description
Activity
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) isglobalPreloadgone.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.
Reacted by Jacob Smith🙋♂️ I'll do the
globalPreloadremoval PR 🙂I'll put together a tech design for import-maps and share it ~next week.
Reacted by Geoffrey BoothDo 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.
Sure. Should be a quick meeting 🙂
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).
Reacted by Jacob SmithWhat and how to document, when to release what, what should be in separate PRs versus not, etc.
Could this meeting be
an emaila 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.Reacted by Jacob SmithCould this meeting be
an emaila 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
globalPreloaditself and its section from the docs, and all references toglobalPreload.
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
--importwithregister(and offering--importwith adata: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-loaderto print a warning that its use is unsupported and that users should instead use--importandregister, with an example of the user’s actual input reformatted as an--importdata URL that runsregisterfor that import. - We remove all mentions of
--loaderand--experimental-loaderfrom 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.
Reacted by Jacob Smith- Remove
- We remove all mentions of
--loaderand--experimental-loaderfrom 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.
--loaderis 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 thanregister().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
globalPreloadis removal has landed (assuming it's going to land).- We remove all mentions of
That’s probably not going to get consensus.
--loaderis 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 thanregister().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 incli.mdbut remove any mention fromesm.md. Since we already don’t document--loaderI don’t think it’s that much of a stretch to limit or eliminate--experimental-loader.Reacted by Jacob SmithGeoffrey's list of things above (#154 (comment)) sounds good to me, and I like the approach of removing
--experimental-loaderfrom all docs acceptCLI, 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--importis recommended and maybe that--experimental-loadermay go away (so it's not recommended); but that may artificially lead to less use of an otherwise popular feature.Reacted by Geoffrey BoothGeoffrey’s list of things above (#154 (comment))
Implemented in nodejs/node#49261 and nodejs/node#49265.
Reacted by Jacob Smith
Time
UTC Tue 15-Aug-2023 18:00 (06:00 PM):
Or in your local time:
Links
Agenda
Extracted from loaders-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
Invited
Observers/Guests
Notes
The agenda comes from issues labelled with
loaders-agendaacross 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