Use cases for module attributes besides module type

[littledan]

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?

[xtuc]

I think another use case would be for tooling; transpilers could tune their code generation based on attributes for instance:

import {a} from "b" with parserPlugin: 'jsx';

or a bundler using loaders:

import {a} from "b" with loader: 'babel';

This proposal allows arbitrary keys so it could be anything.

[littledan]

@xtuc On one hand, this could cause more divergence in the ecosystem. On the other hand, I imagine it may be nicer than maintaining separate configuration files.

[Janpot]

I wonder if it could be useful in testing scenarios? similar to libraries like proxyquire.

import { a } from './my-module.js' with stub: { 'path': './my-path-stub.js' };

It may also be useful for some form of dependency injection?

[weswigham]

Just for reference, this was already discussed in tc39 a bit for the integrity case with these slides.

[littledan]

Thanks for the cross-references, @weswigham. To summarize, @domenic explained why module attributes would be a suboptimal solution for integrity, and the committee agreed. I am not proposing integrity as a primary use case, but given all past discussion, it seemed worth mentioning.

[Jack-Works]

I had done a POC months before to ES import a TypeScript file in the browser directly. I used syntax like

import mod from "/typescript-transpiler.js?path=/src/index.ts"

And I use import.meta.url to get the "self" URL where a path parameter in it. With module attributes, I can write

import mod from '/typescript-transpiler.js' with { path: "/src/index" }; // or whatever the syntax is.
// And I can read import.meta.attributes or whatever in typescript-transpile.js to do the compiler job

This requires re-instantiate the whole module if the module attributes are different but the path is the same.
The previous trick in the URL parameter is working because the browser treats the same URL with different URL parameters as different modules.

I think re-instantiate in module attribute might be a serious problem. Does the current semantic of module attribute support this?

[michaelficarra]

Here's some ideas I have for use cases of per-import-site module attributes:

1. parameters to built-in parsers, such as a reviver for the JSON parser, a content encoding, a start production, etc
2. parameters to built-in validators, such as an expected mime-type, an expected maximum size or object count, a parsing timeout, an expected schema, etc
3. provide a custom parser
4. delayed execution of top-level statements (as in integration of two modules with non-cooperating authors)
5. capabilities
6. specifying security/feature policies to use
7. specifying the realm to execute the module in
8. forced re-execution of a possibly-cached module

The custom parser use case could be solved by having a "text/plain" or "application/octet-stream" type supported where it just gives you what came in off the wire instead of parsing/executing the resource. The capabilities and realms use cases could be solved by instead importing within a Realm as in the Realms proposal.

Notice that none of these would be more appropriately provided via out-of-band metadata because they each may vary at different import sites for the same resource.

[jridgewell]

specifying security/feature policies to use

I brought this up at the end of the December Realms/Compartments meetup in SF. Having the ability to restrict, eg, network access at the import site would be extremely powerful:

const basicThing from 'lib' with { network: false };

Or, just strip all privileged API access:

const basicThing from 'lib' with { privilege: 'none' };

[mstijak]

I'm not sure if it's relevant, but webpack uses magic comments to name chunks or select different modes.

https://webpack.js.org/api/module-methods/#magic-comments