| 20:59 | <peetk> | hello everyone, here is a draft of what we intend to present next week regarding import attributes, following up on recent conversations: https://gist.github.com/peetklecha/a55532165dbd4905aa91bbe59e8b1001 |
| 21:00 | <peetk> | we would really appreciate input before sharing this more widely |
| 21:14 | <littledan> | I missed the last few module calls; is this a good summary of what people were thinking there? |
| 22:25 | <ljharb> | a conclusion in March, or in January? |
| 22:25 | <littledan> | We're going to work on a PR to the import assertions repo, but I don't think we have enough time to get consensus on it this meeting (the PR should be up already to achieve that) |
| 22:26 | <littledan> | so the proposal is to sort of have this two month period to continue working it out, hoping to get consensus on some kind of change to import assertions by March |
| 22:26 | <littledan> | and the "conclusion" from this meeting would be "please hold on, implementers" |
| 22:33 | <ljharb> | makes sense, that's a really good thing to establish asap, to remove the time pressure on figuring things out |
| 22:36 | <littledan> | well, I think we have significant time pressure either way; if we don't deliver on a solution soon, a fairly likely outcome is that we'll have incoherent things shipping more widely. So I hope we can come to consensus on a way through by March. |
| 22:36 | <ljharb> | true enough |
| 22:36 | <Justin Ridgewell> |
I think that's incorrect from TC39's side. We should remove the restriction if we decide to keep using |
| 22:37 | <littledan> |
|
| 22:37 | <Justin Ridgewell> |
|
| 22:37 | <Justin Ridgewell> | It's a stated alternative, which I think badly states the alternative |
| 22:38 | <littledan> | sure, in this alternative then we have two sub-alternatives, but they're both bad |
| 22:38 | <littledan> | the sub-alternatives being, relax the invariant or not |
| 22:38 | <littledan> | (and if relaxed, then how) |
| 22:38 | <littledan> | this document proposes changing the syntax instead |
| 22:39 | <littledan> | there's always lots of alternatives which can be considered! |
| 22:40 | <Justin Ridgewell> |
We can also unnest the dynamic import syntax: |
| 22:43 | <littledan> | maybe! That's a useful kind of bikeshedding which I'd encourage to happen outside of plenary. In plenary, I'd like to focus on getting a shared understanding of the problem space and vague sympathy with the idea that we'd move back from assertions to something else with different syntax and semantics, maybe more like a previous iteration of the proposal (but with some mitigations to address the issues previously raised about unrestricted import attributes) |
| 22:44 | <littledan> | I think we can bikeshed at more length on the details in our loader calls. What's harder is getting that agreement in principle in the change in direction. |
| 22:50 | <littledan> | What do people here think about that change in direction? |
| 23:00 | <Kris Kowal> | Supportive. |
| 23:03 | <Kris Kowal> | Something mildly tragic that is probably impossible to avoid is that the 'css' type will come to generally mean the kind of CSS we have today, which can’t fully participate in the module graph because it imports by URL, not module specifier (and implied 'css' type). It would be nice if we some day had proper CSS modules that would benefit from specifier resolution for their imports. |
| 23:07 | <littledan> | I thought CSS modules weren't allowed to import at all, and that was their way around it |
| 23:07 | <Kris Kowal> | That’s a cool stopgap. |
| 23:07 | <Kris Kowal> | I didn’t know that was the case. |
| 23:08 | <littledan> | we should figure this out... I could be remembering wrong |
| 23:08 | <Kris Kowal> | So, in the future, CSS imports could participate in the module graph with an implicit type: 'css'. |
| 23:09 | <littledan> | what do you mean, implicit? |
| 23:10 | <littledan> | oh, right, an @import within css would have that type by default |