Use cases for module attributes besides module type · Issue #8 · tc39/proposal-import-attributes (original) (raw)

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?