TC39 Module Harmony
2023-02-14
plaintext logs
prev next
source on github
17:05
<nicolo-ribaudo>
Reminder: meeting now! Is anyone else joining?
17:06
<Jack Works>
oh have any interesting topic?
17:07
<nicolo-ribaudo>
Talking about next steps with import assertions and integrations with the other proposals
17:10
<Jack Works>
not coming I need to get up early tomorrow 👀 have a nice day!
17:34
<Luca Casonato>

Justin Ridgewell: what happens with:

import module mod from "./foo";
mod instanceof Module;
await import(mod,  { with: { foo: "bar" } }); // should this throw? I think so!
17:34
<Luca Casonato>
dynamic import must not support with while loading a Module object instead of a specifier
17:35
<Luca Casonato>
if reflection is a with attribute, this would break if you dynamic defer import a module object. ie await import mod, { reflect: "defer" }) vs await import mod, { with: { reflect: "defer" } })
17:36
<Luca Casonato>
dynamic import must not support with while loading a Module object instead of a specifier
because resolution and loading has already occured. the dyn import is a purely ecma262 behaviour.
17:37
<Luca Casonato>
shoehorning reflect into with would mean that with would have a million edgecases related to reflect. like for example reflect would be the only with attribute allowed on a dynamic import of a module object. this is very confusing
19:07
<Justin Ridgewell>
It’s clear that my opinions don’t match the rest of the groups, which is fine. As long as the syntax space is completely open for bundlers (and the attribute loading restriction that’s now removed allows bundlers to use the syntax), I’m happy
19:08
<littledan>
Justin Ridgewell: I guess the proposal is, the with space would be open for bundlers, but the import <keyword> space would specifically not be open, and just be defined by ECMA-262. Would this work for you?
19:08
<Justin Ridgewell>
Yes
21:43
<Justin Ridgewell>

Re future compat concerns, I think we could do either of the following:

  • Open the value syntax so that we can stick bundler concerns into a specific key assert { turbopack: { foo: 'bar' } }
  • Reserve _ prefix for non-TC39 use (alternatively x- prefix, but that forces wrapping keys in strings 'x-foo': 'bar')
21:57
<littledan>
I guess I was convinced by Anne's analogy with HTML tag attributes that it isn't as much of a concern as I was imagining
21:58
<littledan>
I do like the idea of going with a convention which differentiates built-in from custom things