Node.js Loaders Team Meeting 2023-09-26 about loaders

[JakobJingleheimer]

Let's skip 🙂

[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.

[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]

@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).

[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.

[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.