Use cases for module attributes besides module type · Issue #8 · tc39/proposal-import-attributes (original) (raw)
Navigation Menu
- Explore
- Pricing
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Description
The initial use case for module attributes is types, but module attributes had been previously discussed over several years. Some other possible use cases:
- Fetch parameters -- e.g., various policies, authentication options, etc. Unclear how this would interact with caching modules, or how this would be represented
- SRI or other integrity markers -- this interacts poorly with caching, and it may be best to have this out of line in some other yet-to-be-designed resource file
- Marking CJS modules in Node -- this may be a good use of the
type
field - Redirection to find the module within a WebPackage -- I don't know the current state of all this; maybe @nyaxt could clarify if this makes any sense
- Built-in module polyfilling -- now that import maps are not proposed to serve this purpose (initially, a complex module specifier was proposed, so this would be analogous)
For each of these, there would be a significantly greater amount of investigative work to make a real proposal. This repository does not aim to do that work, but I'd like to just understand a bit more about the broader space. Some questions to discuss in this issue:
- Does anyone have any other use cases besides
type
, or comments on the above? - Do strings make sense as values for the additional possible module attributes?
- Do we really think it's likely that we'll eventually want any of them, or will
type
alone probably suffice?