-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loader Configuration #98
Comments
Yes, it’s been on the list of use cases for a while to have some way of specifying loaders that didn’t involve the command line The complication is that if we’re going to allow configuring Node itself via To your specific use case, though, the way I’ve generally seen it handled today is via the |
Another thing that I'm not sure I have seen before is the question of how to configure the loaders themselves. Since a loader is just an imported module, there is no way to pass it configuration other than relying on the file system or environment variables. |
@targos this is possible via CLI args. See https://github.com/JakobJingleheimer/demo-css-loader, specifically https://github.com/JakobJingleheimer/demo-css-loader/blob/6f068d5efc684ea3d4e5f957b030f6ef145e6d64/package.json#L7 |
This is another thing that might get better with nodejs/node#43408. A clear bootstrapping phase for config discovery, with access to information about the entrypoint. This bootstrapper can discover and pass configuration to loaders. Using CLI args seems like a hack since those are meant for the entrypoint, not the loader. A pain point today is that loaders aren't passed an Relative to cwd isn't great for shell scripting scenarios. |
I realized after posting that I can explain more clearly why CLI args are not suitable for configuring loaders. "Seems like a hack" is unnecessarily vague. If I do |
Loaders support top-level |
Yeah but node should probably be passing them a resolved entrypoint path instead of asking them to figure it out themselves (is it an entrypoint? REPL? Code piped to stdin?) or exposing a flag like If node implements a |
Relevant to this, I was just reading https://aws.amazon.com/blogs/compute/node-js-18-x-runtime-now-available-in-aws-lambda/ and noticed this paragraph:
So I guess now it is possible to use |
From my experience, |
This issue is listed under Milestone 2: Usability improvements but for parity with CommonJS it needs to be possible to register loaders at runtime since in CommonJS you can add support for, for example, TypeScript in the current process but there isn't something similar for ESM as far as I can tell. |
With chained loaders being considered as part of this effort, it might become pretty unruly for large apps to benefit from using loaders to help shore up some of the hairy and error-prone sides of the app.
A real-world example here is a TypeScript app that uses GraphQL, Pug, and SQL queries that all need to be loaded using
readFile()
. When building this app, special care must be taken for these files which will not be included in the build from TS since it has no awareness of their existence. But if we could import those files, this would no longer be a problem. Tools can statically analyze the imports and determine which files need to be included in the build artifact, and that's a huge win over not just the current strategy, but other languages as well.This poses a problem, though. How are these loaders going to be maintained for all the various commands you need to run? Does every developer need to have a huge $NODE_OPTIONS defined to ensure the app loads correctly?
I think this could be solved by allowing developers the option to define what loaders are to be run within a package.json. This would allow someone to communicate how loading should work in code, which is transferable to anyone else working on the project.
In keeping with the convention of other JS tools, the configuration should probably be nested in an object of its own rather than be defined on the top level:
This array would be anything importable: a module, file path, etc.
Just a suggestion, and I'm willing to help work this out. But this is very interesting to me as I think loaders in node would open the door to a lot of quality of life improvements, like more sophisticated package management, lint tooling, and all kinds of stuff.
The text was updated successfully, but these errors were encountered: