Came here to suggest exactly this. In fact, it is somewhat surprising that type: 'text' wasn’t the very first import type to be defined, as all others are basically a specialization of that.
Having a more generic type: 'text' to fall back on would be great for paving the way for other types too as it allows opting things into the module graph even if they require some post-processing by the importing module. Because it is not dependent on any particular host environment, it can work much more broadly and be defined by the core ES spec to be always available.
E.g.
- many uses of
type: 'css'would actually be fine with justtype: 'text' import 'foo.yaml' with { type: 'text'}which would then be processed into actual YAML by the importing module.import 'foo.html' with { type: 'text' }which would then be used by a web component as a template, even before HTML modules are fully a thing.
type: 'text' may not be a first-class solution for many use cases, but it provides a lower level workaround for many, alleviating some of the need for host environments/languages introducing new types for very specific things.
I think the MVP is just type: 'text' though, no encoding or other parameters. ES already knows how to read and resolve modules. This is basically equivalent to wrapping the entire module code with export default <module content as string>.
Down the line, we could even introduce fallbacks, so that people can do things like import 'foo.css' with { type: ['css', 'text'] } for brand new types and then polyfill them in their module code.
@claudiameadows wrote:
For that, you could just aggregate them all into a JSON file (or something you can compile to that) and import that instead. Would result in a lot fewer downloads for one.
That assumes a double handshake, which is not always feasible. E.g. tooling often needs to be able to process files in their original format (in fact, this may be the first step of aggregating them like this). As for downloads, not all ES is executed in the browser.