Showing content from https://github.com/tc39/proposal-import-attributes/issues/8 below:
Use cases for module attributes besides module type · Issue #8 · tc39/proposal-import-attributes · GitHub
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?
SalathielGenese and styflethescientist13
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4