| 21:40 | <littledan> | lol I'm going to be extremely dead at our meeting tomorrow, after a whole-day Ecma GA meeting |
| 21:42 | <littledan> | Anyway I'd like us to discuss this somewhat urgent issue of the relationship between import assertions and HTML--the web platform might not actually support module types in the "assertion" style we were imagining. https://github.com/tc39/proposal-import-assertions/issues/125 |
| 21:42 | <littledan> | I've invited Anne van Kesteren as our special guest (now of WebKit, formerly Mozilla) |
| 21:43 | <littledan> | This is time-sensitive both because the proposal is already at Stage 3 and because it's under consideration for "Interop 2023", which would accelerate its implementation in other browsers |
| 21:43 | <Kris Kowal> | Always good to cross paths with Anne. Thank you for reminding me that this is an odd-numbered week. |
| 21:43 | <littledan> | Fundamentally, the problem is: The Web actually wants to make requests to the server in different ways depending on which kind of resource is anticipated. That changes the interpretation of the module and is not consistent with the "assertion" invariant. |
| 21:45 | <littledan> | I'd add: the fact that HTML folks have been discussing this idea for a year and didn't notice the mismatch is kinda a mark against the "assertion" mental model. (The initial discussion was about CSP checks on the response, but the HTML people should've been thinking about the effects on the request too, which isn't as obvious to us humble TC39 folks) |
| 21:45 | <Kris Kowal> | In my estimate, that will force our hand into incorporating the type in the module instance’s memo. At least we can be explicit about that in 262 now that we’ve borged the logic for loading. |
| 21:46 | <littledan> | well, it'd be as simple as deleting a line |
| 21:46 | <Kris Kowal> | And if we entertain this, I’m in favor of renaming assert to with as soon as possible. |
| 21:46 | <littledan> | but, we'd have to think about the implications... |
| 21:47 | <littledan> | yes, certainly the keyword assert doesn't make any sense at all if we made that simple change you're thinking of |
| 21:47 | <littledan> | we'll need to think about whether this is the change we want to make |
| 21:47 | <Kris Kowal> | It’d imply that importHook needs to accept the type as an optional argument. We would want to be very clear that this is the only additional term of the module memo keyspace we’re considering. |
| 21:48 | <Kris Kowal> | As a safety, we’d probably also want the Module to have a type so the importing Module can make sure it gets what it asked for. |
| 21:48 | <Kris Kowal> | Otherwise we have a maybe-ignore-the-requested-type footgun. |
| 21:49 | <Kris Kowal> | It’s a considerable complication, but if it’s table stakes, we can do it. |
| 21:49 | <littledan> | The two things which would be strongly dispreferrable to me are:
|
| 21:50 | <littledan> | I actually noticed that the HTML spec says it is a willful violation when it actually isn't! I need to file an issue on that |
| 21:50 | <Kris Kowal> | How is it not a willful violation if the author knew to write that it was a willful violation (as opposed to accidental?) |
| 21:51 | <Kris Kowal> | Change of authors? |
| 21:51 | <littledan> | I'd categorize HTML's current use of the assertion--just to duplicate a cache entry but not to actually make the request differently--as a not-significant-enough way of using the type which makes it not so bad that it's omitted from the import hook |
| 21:51 | <littledan> | it was a willful violation in a previous draft. We went out of our way to make it not a violation, but I guess that wasn't noticed by the editors of HTML. |
| 21:52 | <Kris Kowal> | I must have missed that gambit. |
| 21:52 | <littledan> | and there were lots of strong opinions flying around, including strong expectations that we wouldn't ever have alignment (from both sides!) |
| 21:53 | <Kris Kowal> | I agree creating a duplicate cache entry as a side-effect is expressible with an importHook without threading the type, and is at least required for other kinds of redirects. |
| 21:53 | <littledan> | oh it is? |
| 21:53 | <littledan> | that's not what I was saying but it's sort of a relief if so |
| 21:54 | <Kris Kowal> | Ah, well, maybe not so great for type not to be virtualizable. |
| 21:54 | <littledan> | It’d imply that as syntax which Guy initially used to present import reflection... |
| 21:54 | <littledan> | we tried to be super general with import assertions but then we don't really have enough supporting use cases |
| 21:54 | <Kris Kowal> | But importHook does need to make notes about redirects and symbolic links in some cases, so it produces consistent results for all ways to address an identical module. |
| 21:55 | <littledan> | I guess it just makes those notes for node-like environments. In the web it doesn't/ |
| 21:55 | <littledan> | it just identifies them as different modules |
| 21:55 | <Kris Kowal> | I’m pretty sure import reflection is orthogonal. |
| 21:56 | <Kris Kowal> | it just identifies them as different modules |
| 21:56 | <littledan> | I’m pretty sure import reflection is orthogonal. |
| 21:56 | <Kris Kowal> | Aye. |
| 21:57 | <littledan> | Presumably import-map is doing the work of emulating what Node.js does for a published artifact. |
| 21:57 | <Kris Kowal> | That’s surprising. |
| 21:57 | <littledan> | I mean, native modules on the web omit solutions to lots of problems... and they aren't used so much... maybe there's a connection |
| 21:58 | <Kris Kowal> | There is no emoji for my face right now. |
| 21:59 | <Kris Kowal> | In any case, this is a good topic for the agenda and I look forward to it. |
| 22:02 | <Kris Kowal> | I’m also interested in discussing how we go forward given bakkot’s express desire to “not introduce another path to eval”. That’s the one piece of feedback I believe we either need to address or argue around to advance Layer 0. I think there’s a coherent thinner sliver we can bring to the next plenary, where there are module sources but no ModuleSource, where we recover Layere 0 (grammar validation) Layer 1 (binding reflection) with a Module.parse. |
| 22:03 | <Kris Kowal> | I believe that maneuver still covers most of the motivating use cases, given that we grudgingly can fall back to Module.parse(source); (0, eval)('module {${source}}') (note ticks to avoid confusing markdown) |
| 22:04 | <Kris Kowal> | And of course, that also allows us to revisit ModuleSource when less reasonable folks come out with picks and torches some years hence. |
| 22:06 | <littledan> | huh, I think it'd be fine to have the ModuleSource class, and just its constructor throws |
| 22:06 | <Kris Kowal> | And, on the other hand, to make sure we’ve communicated the mitigating nuances of our design, I think we should separate ModuleSource into another layer and explain its mitigating qualities for CSP, just in case that was missed. |
| 22:06 | <littledan> | like the whole same design, just without that part |
| 22:06 | <littledan> | yes the fallback would be bad due to injection... |
| 22:07 | <Kris Kowal> | Yeah, I’m okay with that too, though it’s not necessary. |
| 22:07 | <littledan> | Wait Module.parse? Wouldn't that be another path to eval? |
| 22:07 | <littledan> | I thought bakkot was saying we should'nt have that |
| 22:07 | <Kris Kowal> | Right the fallback would be bad for injection, but as long as you Module.parse first, safety is recoverable. |
| 22:07 | <littledan> | well but would bakkot be OK with Module.parse? |
| 22:08 | <Kris Kowal> | No, Module.parse gives you parse but not eval, and doesn’t provide an object you can expect to pass to Module, so therefore no path from arbitrary string to evaluation. |
| 22:08 | <littledan> | what does it return? |
| 22:08 | <Kris Kowal> | That’s a question I need to ask. |
| 22:08 | <Kris Kowal> | Module.parse would return { bindings }. |
| 22:09 | <Kris Kowal> | Or throw SyntaxError. |
| 22:09 | <littledan> | I'm not really convinced... I think we should be making more of an all-or-nothing decision |
| 22:09 | <littledan> | (I'm open to being persuaded) |
| 22:10 | <Kris Kowal> | My preference is to convince all relevant parties that what we’ve already proposed is good. |
| 22:10 | <littledan> | Yeah I like the ModuleSource constructor |
| 22:11 | <Kris Kowal> | But barring that, I’d like to make monotonic incremental progress and not preclude the possibility of going back for what’s left behind. |
| 22:11 | <littledan> | it would certainly have to be taken seriously as another entrypoint to eval, I agree with that |
| 22:11 | <Kris Kowal> | Same. |
| 22:11 | <Kris Kowal> | I will now feed the child. Back in a bit. |
| 23:18 | <Kris Kowal> | And back. |