TC39 Module Harmony
2022-07-19
plaintext logs
prev next
source on github
00:01
<Kris Kowal>
That in turn is important because one of the things you can do with a module source is relocate it, e.g., from the file system to a bundle, or a zip file.
00:01
<littledan>
Oh I see
00:01
<Kris Kowal>
In which case the import.meta.url is not applicable.
00:01
<littledan>
And this is supposed to be the resolved specifier?
00:01
<littledan>
Not a relative one
00:01
<Kris Kowal>
Yeah, referrers need to be fully resolved. What that means can vary as well.
00:02
<Kris Kowal>
e.g., if you have an importHook per scope, ./src/main.js is a very reasonable fully-resolved specifier, where ./ just distinguishes a module in scope from one that’s from another scope.
00:03
<littledan>
OK, then I agree that this is orthogonal. Then, WebAssembly.Module needs a referrer as well as host data
00:03
<littledan>
Since, when used in import, it needs to resolve relative references
00:03
<Kris Kowal>
My position remains that Module needs a referrer and import reflection can produce a Module that contains a WebAssembly.Module as its source.
00:04
<littledan>
That would mean that it can’t be multiply instantiated, going against one of the core goals
00:04
<Kris Kowal>
It can be multiply instantiated.
00:04
<littledan>
That goal is higher priority than my import() one
00:04
<littledan>
How can a Module be multiply instantiated?
00:05
<Kris Kowal>
await import(new Module(module.source, module.referrer, etc.))
00:05
<littledan>
OK, by cloning it
00:05
<Kris Kowal>
Effectively, yes.
00:05
<littledan>
By projecting away some of the stuff
00:05
<littledan>
Well, these are two coherent points in the design space to consider
00:06
<Kris Kowal>
Aye.
00:06
<Kris Kowal>
I’m just strongly against adding the referrer to the source. There are other coherent ways to meet that criterion too.
00:07
<littledan>
Can you say more about why?
00:07
<Kris Kowal>
Including an intermediate layer between source and instance. I’m weary of that though. Not a naming problem I want to get into.
00:07
<Kris Kowal>
Yeah, sources are highly reusable.
00:08
<Kris Kowal>
They can be backed by an immutable record that can be safely shared throughout an agent cluster without synchronization.
00:08
<Kris Kowal>
And they represent no authority.
00:09
<Kris Kowal>
Taking referrer onto that does not add authority, but it does make it less clear exactly how cache and share friendly they are.
11:18
<Jack Works>
I feel good with no referrer (current PR design). Is there a summary of why we want to add it back again?
11:21
<Jack Works>
is this a feature or a bug?
11:23
<nicolo-ribaudo>
A feature! The exact code does not matter, but the amounts does. It's to show that compartments a small implementation on top of all the building blocks (or at least, that's what I remember from when I saw that slide!)
12:45
<Kris Kowal>
is this a feature or a bug?
Intentional. I don’t want people to read the whole slide, but I do want to give people an idea about how much code it takes to implement compartment in user code. Whether this is okay or too much is actually quite subjective. For an inline implementation of import map that gets written into a large portion of the web, might be too much. But, on the other hand, might not be.
12:47
<Kris Kowal>
I feel good with no referrer (current PR design). Is there a summary of why we want to add it back again?
Yes, importMeta is mutable and referrer should not be. This is a soft requirement. If we also make importMeta === import.meta, that requirement becomes harder: a module should not be able to alter its own referrer between dynamic imports. I’m leaving these all as open questions for us to settle amongst us and am not going to broach the topic at plenary.
12:48
<nicolo-ribaudo>
Could the referrer be in a private field of importMeta not visible from inside the module?
13:36
<Kris Kowal>
It could be. The other way of looking at this, though, is, "what among the properties of import.meta are useful to an importHook", and the answer is, "only the referrer".
13:37
<Kris Kowal>
And another way to look at it is, "what does one need to construct an import.meta for a particular module", and the answer is, "only the referrer".
13:37
<nicolo-ribaudo>
It could be. The other way of looking at this, though, is, "what among the properties of import.meta are useful to an importHook", and the answer is, "only the referrer".
Well, you have an example with import.meta.resolve
13:38
<nicolo-ribaudo>
I can answer to myself 😂 With Guy's proposal of passing a baseURL parameter, you don't need to get .resolve from the module's import.meta
13:38
<Kris Kowal>
And another overlapping design question remains open: can we thread importMeta such that import.meta === importMeta and cause less confusion?
13:39
<Kris Kowal>
Where is Guy proposing the passage of a baseURL?
13:39
<nicolo-ribaudo>
And another overlapping design question remains open: can we thread importMeta such that import.meta === importMeta and cause less confusion?
I agree that it's confusing
13:39
<Kris Kowal>
Is this different than import.meta.url?
13:40
<nicolo-ribaudo>
Where is Guy proposing the passage of a baseURL?
Adding a baseURL parameter to import.meta.resolve, so that it can be reused across modules: https://github.com/whatwg/html/issues/8077
13:42
<Kris Kowal>
Oh, indeed. I think that’s orthogonal too. The baseURL is presumably optional and defaults to import.meta.url, such that resolve still closes over import.meta.url?
13:42
<Kris Kowal>
Basically revealing the underlying uncurried form of resolve.
13:43
<Kris Kowal>
There are some tangles there. I know that we can’t do that in Endo, since there isn’t a URL and each package has an isolated namespace.
13:50
<Jack Works>
It could be. The other way of looking at this, though, is, "what among the properties of import.meta are useful to an importHook", and the answer is, "only the referrer".
import.meta.hot
13:52
<Luca Casonato>
We’re skipping the loader meeting this week, right?
13:52
<Luca Casonato>
(Because plenary)
13:53
<littledan>
yes
20:25
<yulia>
Kris Kowal: i didn't realize you would be going last today. I will probably fade before then
20:26
<yulia>
are you expecting any major decisions made on your proposal today? or is this primarily an update?
20:26
<Kris Kowal>
this is an update and we're not calling for decisions yulia
20:27
<Kris Kowal>
we are looking for whether the motivating cases are well-supported for each layer
20:27
<yulia>
ok, I will review the notes after
20:27
<yulia>
interesting discussion to have though
20:27
<Kris Kowal>
you'll be missed and thanks
20:28
<yulia>
one comment on the repo so far -- i think the one thing i am missing is a motivation
20:28
<littledan>
maybe we can rearrange the presentation to come in a future day?
20:28
<littledan>
it'd be nice to have you present
20:29
<littledan>
(unless you prefer to be absent)
20:29
<Luca Casonato>
I think it's locked to today because constraints for Shu & Nicolò
20:29
<littledan>
I see
20:30
<yulia>
I think it may be useful to have one line. for example: https://github.com/tc39/proposal-compartments/blob/master/0-module-and-module-source.md -- the motivation here might be: "currently we have a conflation of two concepts in module records. This makes it difficult to work with these separately. By separating them, we unlock the following use cases"
20:30
<yulia>
its kind of like the synopsis, but it frames the layer in terms of what it is solving. that may help with establishing motivating cases
20:31
<yulia>
I would prefer to be present -- the problem is that i didn't really sleep last night. I don't think i am critical though
20:31
<yulia>
i probably am for import reflection so i will be here for that
20:33
<yulia>
my audio is messed up anyway
20:33
<yulia>
ill go through the other layers now and mention what i find
20:34
<Kris Kowal>
I think it may be useful to have one line. for example: https://github.com/tc39/proposal-compartments/blob/master/0-module-and-module-source.md -- the motivation here might be: "currently we have a conflation of two concepts in module records. This makes it difficult to work with these separately. By separating them, we unlock the following use cases"
i will have to touch on this, though i probably could not stop on just the division of source and instance.
20:35
<yulia>
i think setting up the problem statement in the clearest possible way would be great -- even if its more than what i described there. That was just my naive starting point!
20:35
<Kris Kowal>
thank you for pointing that out though. it is a blind spot for me.
20:45
<yulia>
for this one, the motivation works as a problem statement: https://github.com/tc39/proposal-compartments/blob/master/2-virtual-module-source.md#motivation -- it states what can not be done today and why we want to do it.
20:47
<yulia>
this one is a little hard to understand: https://github.com/tc39/proposal-compartments/blob/master/1-static-analysis.md#motivation -- in particular, i start to get confused at "The weight and performance of a JavaScript meta-parser (about 1MB) often precludes production use-cases that make direct use of JavaScript module source. " -- by meta-parser what do you mean? Like syntax only parser? something else?
20:50
<yulia>
this one, i need to spend with more time but on first read it looks fine: https://github.com/tc39/proposal-compartments/blob/master/3-evaluator.md#motivation
20:51
<yulia>
and, my attention is fading -- so i don't think i can do any more
20:51
<yulia>
ill come back to it at a later point, id like to spend more time with this in general
20:52
<Kris Kowal>
ty!
21:31
<yulia>
I think, module <identifier> from "xyz"; might be interesting?
21:32
<yulia>
with module <identifier> { ....} and const <identifier> = module { ... }
21:32
<yulia>
but then if assert is in the same position its a little weird
21:32
<yulia>
cc guybedford (Guy Bedford)
21:32
<littledan>
this conflicts a lot wiht module fragments
21:32
<littledan>
which use module identifier { }
21:33
<littledan>
I think we should use the import keyword here
21:33
<yulia>
module reflection: module <identifier> from "xyz"; module fragments: module <identifier> { ....}
21:33
<nicolo-ribaudo>
I like "import" because we are still "loading something external", but this doesn't conflict: it aligns well
21:33
<yulia>
so we will have
21:34
<yulia>
import module <identifier> from "xyz"
const whatever = import(<identifier>)
21:34
<yulia>
and these two will mean very different things
21:34
<littledan>

here's another possible interaction point between import module and module fragments:

import module foo from "./foo.js";

module bar {
  import foo;
}

I like it!

21:35
<Jack Works>
import foo from "spec" as module?
21:38
<yulia>
I was additionally thinking of how to handle the dynamic import case, which could be (if there is flexibility to consider other approaches) module(<url-specifier>) followed by import(<module>)
21:39
<yulia>
or, module import(...) and module import x from "xyz"
21:41
<nicolo-ribaudo>
module(<url-specifier>) is already valid syntax, and module import(...) feels weird to me because the space has an higher precedence than (...) (reading it as a function call) 😬
21:41
<nicolo-ribaudo>
I think using the options bag would be fine
21:41
<yulia>
yeah, the import statement is a bit weird
21:42
<yulia>
I find the new syntax confusing though.
21:42
<yulia>
I wouldn't know, as a developer, how this "module" is different than what i already imported
21:43
<yulia>
from what i was already importing with the regular import statement rather
21:44
<littledan>
I like the import(..., {xyzkey: "module"}) syntax presented; I think we could use some bikeshedding on the key
21:45
<littledan>
I mean, we designed import assertions specifically to enable this case
21:45
<littledan>
the second argument design, I mean
21:46
<nicolo-ribaudo>
I wouldn't know, as a developer, how this "module" is different than what i already imported
I think that the compartments proposal reifying Module/ModuleSource will help with that confusion, because "module" becomes a real word of the language
21:47
<nicolo-ribaudo>
We must make sure that they don't mean incompatible things
21:48
<yulia>
Fair, I’m still working through that proposal. I’ll return to this later
21:48
<yulia>
Night all
21:48
<nicolo-ribaudo>
Have a good night!
22:36
<littledan>
Maybe there is some sort of more restricted form of evaluators that could meet Shu's concerns. I'm not sure what that would look like, though.
22:39
<Jack Works>
how you can restrict it? I think it's already a minimal one
22:40
<littledan>
I'm not sure; one option is what Kris is saying
22:40
<littledan>
I suspect there are multiple options that meet these goals