littledan: you may interested in this prototyping

my concerns came up during import assertions, and are very documented; i don't think i've documented yet how my fears exactly came true as predicted as tools tried to inject all sorts of wacky syntax forms into assertions

and they use import x from "!raw-loader!./file.txt" in days before.

yes, and the ecosystem recognized how terrible that is which is why it's been a bad practice to use webpack-specific loader syntax for a long time

• Importing an image with blurry placeholder, intrinsic size, etc.
• Import bytes buffers
• Transforming files for the importer's usecase
• Annotating metadata
  (these are just the things I did last week)

Well, for example Module/ModuleSource can solve the first three by providing custom module loaders

I can't have a bunder output that uses eval() in any form

FWIW I lean towards what Justin is saying and sort of regret naming the keyword “assert” for that reason. I don’t feel like the assertion mental model resonates with anyone.

Like, isn't that the same suggestion as using Comparentments/ModuleSource/etc?

The problem space is more than WASM

i also feel like it could have been named differently, but that has past -- does everyone have objections to with?

yes, i'm very opposed to extensible syntax in unknowable ways that will fork the language

assertions can already be arbitrary

This already exists in the ecosystem

the JS ecosystem has imported JSON for over a decade via require('./path/to/file.json'). it's well-understood and quite intuitive

im even not sure if we should add something like with or if we should really just expand on assert because its already getting confusing

the semantics of assert are always "either it works or it throws"

yulia: But as I've said, in TS, there already is a special syntax for special imports, called type imports, and it is written like that: import type { MyType } ... so for at least TS developers this would not be different, but I also object to the wording/naming of module.

yulia: But as I've said, in TS, there already is a special syntax for special imports, called type imports, and it is written like that: import type { MyType } ... so for at least TS developers this would not be different, but I also object to the wording/naming of module.

if we have import module/source/lazy whatever -- we should not have import type

Does the strength of your conviction extend to precluding WASM from participating in the ESM graph?

why would i preclude that?

I must be misunderstanding your objection. Are you objecting to JSON participating in the ESM graph?

i am objecting to mixing roles and making additional syntax for developers to read, without being strict about what different parts of the import statement mean

yes, with is potentially extensible, but we are potentially, as a committee, going to add more of these

hosts are only allowed to reject or not based on assert; they can't provide different representations based on it

im even not sure if we should add something like with or if we should really just expand on assert because its already getting confusing

you might have to figure out what the various assertions are, but you don't have to figure out what they do

But you do. You have to know that assert { type: 'json' } turns into a default import of an object (and no named imports). type: 'css' gives you a StyleSheet and no class names, etc. These are already reflections mixed with asserts.

I turned non JS into a JS module

Hold my beer. I turned HTML into a reactive Lisp compiles down to JS.

We're here to solve the ecosystem's needs

imo some node collabs suffer from a similar problem; in a panic over “but what if people use something else” they end up trying to make node into something it shouldn’t be. if a better platform exists, good, people should go use it

the module blocks/compartments proposal has a load func or similar right?