This repository was archived by the owner on Sep 2, 2023. It is now read-only.
This repository was archived by the owner on Sep 2, 2023. It is now read-only.
Pluggable Loaders to support multiple use cases #82
Closed
Description
As #81 is getting into implementation details of the loader I thought it might be a good idea to start discussing an idea I have been kicking around for a robust solution. "Pluggable Loaders". This is heavily inspired by nodejs/node#18392
TLDR; (bluesky)
- Loader Plugins can be specified via an out of band mechanism (a.k.a. package.json or command line argument).
- Loader Plugins can included within a project as an es module or installed via a package manager
- Loader Plugins can specify the behavior of the loader including
- behavior for specific extensions or mimetypes
- behavior for lack of extensions (e.g. path searching)
- Loader Plugins can cascade
- plugins can override default behavior
Example loaders include
- std/esm
- TypeScript
- wasm
- Babel
Questions to be answered
- Is this approach of interest?
- Should plugins be specified per application or per package
- What should node ship as default loaders?
- Proposal
- Package name map as default loader
- "Legacy" loader shipped in core as well
- Proposal
Thoughts?