diff --git a/doc/meetings/2019-03-13.md b/doc/meetings/2019-03-13.md new file mode 100644 index 0000000..a33dc85 --- /dev/null +++ b/doc/meetings/2019-03-13.md @@ -0,0 +1,228 @@ +# Node.js Foundation Modules Team Meeting 2019-03-13 + +* **Recording**: https://www.youtube.com/watch?v=0vB55lvVqFc +* **GitHub Issue**: https://github.com/nodejs/modules/issues/292 +* **Minutes Google Doc**: https://docs.google.com/document/d/1N2pz8grs6WpOymgo862T3al3EwIwL7bo7ovwLxyPqtQ/edit + +## Present + +- Myles Borins (@MylesBorins) +- Michael Zasso (@targos) +- Jordan Harband (@LJHarb) +- John David-Dalton (@jdalton) +- Wesley Wigham (@weswigham) +- Guy Bedford (@guybedford) +- Saleh Abdel Motaal (@smotaal) +- Gus Caplan (@devsnek) +- Rob Palmer (@robpalme) +- Daniel Rosenwasser (@DanielRosenwasser) +- Geoffrey Booth (@GeoffreyBooth) +- Jeremiah Senkpiel (@Fishrock123) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs with no blocks (6 minutes) + +2 minutes per item. + +* Cpp Refactoring Ensuring avoiding duplicate package cache [#58](https://github.com/nodejs/ecmascript-modules/pull/58) + * No objections + +Land away + +* esm: add experimental .json support to loader [#43](https://github.com/nodejs/ecmascript-modules/pull/43) + * Functionality: No named exports, default only + * No objections + +* Warn about `--type` with shebang [#37](https://github.com/nodejs/ecmascript-modules/pull/37) + * Punting on this +### Discuss PRs that have blocks (10 minutes) + +* ESM_FORMAT: Avoid reading package.json when extension is unambiguous [#33](https://github.com/nodejs/ecmascript-modules/pull/33) + * Jordan: If it's premature optimization, don't do it because it could be a distraction + * No objections to not landing...so… + * Not doing it yet! +* esm: scoped `--type`, cpp refactoring [#57](https://github.com/nodejs/ecmascript-modules/pull/57) + * Need to clarify whether `--type` is a mode. + * When set to esm, all `.js `files are ESM, commonjs implies `.js` is CJS. + * Alternative viewpoint is that it's the parsing goal for the entrypoint. + * Explicit signal is only needed, if no package.json, or no extension (and no package.json) + * Jordan: Objects to a mode. `.mjs` is ESM. `.js` is CommonJS. The defaults are there for a reason. `.js` should never default to anything but CommonJS (absent an overriding explicit per-file signal). + * Guy: use-cases are good starting point for file that has no package.json; problem is when a file has a relative import to a sibling module with a `.js` extension + * If another file imports your entry-point as a dependency, that means your code can behave differently. + * Should we instead think of the type as the same as putting a `package.json` in the folder that contains that type. It’s like a virtual package.json. + * Current behaviour it is only an entrypoint. + * Gus: --type is a really blunt tool to use. File has been affected by another file importing it. At that point you should be using package.json. + * Myles: Field for CLI and package.json need to have the same name or we'd confuse people. I like the idea of flipping modes without package.json. Thinking of it as flagging the entrypoint is useful but more confusing. That Developer Experience should not call the command line flag “type”. +Salah: Consider usefulness. If type is module, it’s really about semantics of file execution. Type flag is for toggling the mode of things that load other things? Or is it just setting semantics? +Jordan: Importing means nothing about the target. It could be WASM - more than just CJS/ESM. +JDD: I assumed --type was another way to do package.json type field - discovered differently in the PR! Creating the virtual package.json is fine by me. +Geoffrey: If we don’t have it like the fields, type=auto is useless. Not sure why we didn’t do it like the field - it still solves the one-off case and other cases. Can experiment with “let’s just try running it as ESM”. +Jordan: I object to this mode. +JDD: Vote? +Myles: We wanted to open a PR this week. Consensus is ifi it’s called types, it should match package.json but Jordan doesn’t like this. +Jordan: We can bikeshed the name outside. +JDD: Unless it’s like “type”, we should not do it. +Guy: Could call it --format? +JDD: I have experience with API design. I disagree with it. +Geoffrey: People are opposed to a flag over editing files? +Jordan: I am concerned about a world where people pave over the reasons .mjs exists. +Salah: If you like running with the flag on, you get the right results, or you fix your scripts. People have to make good choices. +Myles: I believe keeping it as --type and same as package.json is better - it is easier to learn. If we introduce a whole new thing to learn, it’s not a relevant or useful feature. The intent is what Guy is providing. +Jordan: This is not what I was told. We should revert it until we have consensus, or we slip schedule, or rename flag. Need more time to talk about it. +Myles: so for now, change the flag to be mode and only apply to entrypoint. +Geoffrey: I object - ship it as is and users can complain. +JDD: Let’s revert if we don't have consensus. +Jordan: We can revert if changes are fully discussed first. +Myles: This allows unwinding any consensus. I understood the implemented behaviour. +Jordan: Discussion on PR was misunderstood. +Myles: Majority here agree on behaviour. Multiple people object to your alternative. +Guy: This has always been unclear to me. The elegant behaviour is to operate at a scope level, but it’s non-obvious. I have no opinion either way. So what is the harm of renaming? +Geoffrey: It will never be the user’s intent. +Guy: We can use bug reports from users based on feedback. And therefore it needs to be renamed. What’s the risk of shipping? +Salah: You have to make people assume the right thing to get data. +Myles: Objection for renaming when we upstream? +Geoffrey. Yes +Object to landing the PR? +Jordan: Yes. +Myles: Leave it how it is. Current situation is the worst for everyone. + +### Upstreaming (25 minutes) + +* discuss ‘.cjs’ [#293](https://github.com/nodejs/modules/issues/293) +Myles: In module mode, there is no way to import CJS without it. +Geofrrey: This is why is was added: +Jordan: Agree, when you have a mode. In absence of extension map, you’re right. But I don’t like modes. With ext map, you can make any extension you want be CommonJS. Until we have strong consensus on modes. +Yles: We have consensus on modes. It landed. Stuff relies on this. Removing it now makes the DX unusable. +Jordan: You’re saying the concession is something I should not have done. I said “this should not exist when we have extension map”. +Myles: We can revive it when we have ext maps. We can’t remove it now. +Jordan: Worried about ecosystem relying on it. I intend to remove it in future. +Myles: Today you can require an extension that doesn’t exist it falls back to CJS. +JDD:It’s super cool. +Jordan: Requiqr with explicit extension falls back to cJs? +Myles: Yes +Jordan: So we don’t need special handling of CJS. +Myles: This is specific to our loader. Can be overridden by export maps later. In CJS it will fallback to CJS. In ESM it will fallback to ESM. +Jordan: We should think more about this. Good to hear it works today! It’s necessary to have new extensions for new parsing goals. Concerned about setting expectation that CJS should be in CJS files. +Myles: But we need ESM mode where we make it easy to import CJS without that extension. People shouldn’t have to opt in to import maps just because they want to use CJS from ESM. +Salah: Will it be more problematic to use CJS from ESM mode if we remove the mode? +Jordan: I want to talk about Wes’ comment. +Gus?: If you want to use .js but you need to rename CJS, why not just rename your .js to .mjs. The use-case here seems to be to avoid .mjs. +Geoffrey: CoffeeScript needs .js! Tools, transpilers need it and allow mixing. +Gus: Does your build tool understand .cjs? +JDD: I like the symmetry of .cjs. Future is ESM. So CJS is legacy. So the wart should decrease over time. +Myles: Does anyone object to .cjs? +Jordan: Not a fan. Would like another solution. It is hostile to the ecosystem that needs .mjs +Myles: I disagree. We have no other code with another approach. You’re saying we remove the current reference to .cjs - does anyone object? +Geoffrey: Yes, I object. There’s value in what we have. We can flip the default in future. +Jordan: We could add cjs later. +Myles: We are in the same as --type. We don’t have an approach. Does anyone object to continuing forward? +Jordan: CJS snuck in. I do not view it as having consensus. +Myles: You are forcing a deadlock for the second time. +Jordan: Any alternative needs to remove CJS, but there’s no consensus to remove. +Gus: There’s a lot of work to implement a loader. IT’s different to having something built in that works. +Myles: a package.extensions that has a mapping with translaters could exists, but there’s no implementation. +Jordan: I filed an issue a week ago. +Jeremiah: It unclear to me when loaders will happen. I don’t see this solving itself. +Myles: Jordan, you object to shipping .cjs and is disingenuous and you wouldn’t have agreed to it if you had known. But you have not brought an alternative. +Jordan: You don’t need to write code to object to decisions. I filed an issue for the extensions map. IT’s straight forward. Mentioned 18 months ago. The responsibility is not only on the objector. The shipper must do the work. If folks want to ship the type flag, and I want import map, they can implement that. Writing code is not a requirement. +Myles: But no implementers means it’s not happening. +Jeremiah: Our governance is different. +Geoffrey: shall we vote? +JDD: If deadlocked, that’s the next step. +Myles: I apologise for the approach. We do not have consensus on type, or modes, or landed stuff - the entire implementation. +Jordan: Not everything. Type is an enhancement - we could remove it. Altering the defaults is something people should have. +Myles: Go back to package type? +Jordan: we might want to do it, after we get extension maps. Yes it’s still on the table. Just because it has landed does not make it permanent. +Myles: We have minimal kernel, package types. It feels like you are unwinding consensus. +Jordan: Not proposing to remove … Its presence in the implementation does not imply consensus. IT should not accelerate other ideas unless we say it doesn’t have consensus. +Myles: How should we move forward? +Jordan: It’s frustrating if I suggest things but can’t do it. Sorry. I want to see extensions map go in. So ergonomics of CJS no longer applies. Then, having type:esm be sugar for an extensions map - needs thinking time - might be less problematic. It does not force file extension opinions. Makes me feel better about shipping type sugar. Then we’re saying, this is common, but you can do any pattern. Want extensions map, then we have pleasant discussions because we’re talking about refinements. +Myles: Objections on this path forward? +Guy/Geoffrey: We object. It’s not an argument. It’s about UX. It doesn’t matter if there is a more foundational way to define extensions. We’re designing UX in Node. +Jordan: No - we’re doing both. +Salah: We’re throwing experimental modules, the default mjs does not exist except in the old. We started fresh and there’s no default. So mjs goes out the window. +Jordan: We reacquired consensus for MJS being default. +Salah: I never voted on that. +Jordan: The needs are still there. +Myles: We have not achieved much today. +Jordan: [to Guy] we are trying to design the most perfect system we can. We can’t know how this will be used in future. Usability comes from ability. In future, people may want to use arbitrary extensions for arbitrary things. You can’t say people don’t want this. +Guy: I believe those cases will be fulfilled by loaders. Loaders are the more powerful way to deal with arbitrary extensions. I don’t object to extension maps, but don’t see where it gets us. How does it move us forwards? +Wes: Text editors. Arbitrary extensions are great. TypeScript and IDEs don’t support arbitrary extensions. There’s a reason we’re not fixing it. There are way more people who are happy with defaults. I don’t think the ability to have arbitrary extensions should block shipping. We have regular traffic on .mjs. Unless you tell lots of people to use it, they won’t use it. Don’t see why it needs to be a requirement. +Myles: Jordan, you said type could be sugar for an export map. It’s reasonable that in mode module, where .js is ESM, it’s likely we’ll want to map common js from one. There’s not much userland difference. Seems to me that waiting for exports should not block type stuff right now if it eventually turns into sugar. +Jordan: Agree, technically. My concern is about messaging and best-practice. Modules is a place where we create implicit recommendations. +Myles: When we get extension map, we’ll want a sugary default. So we end up in the same place. +Jordan: It enables very different forms of feedback. +Myles: Are you blocking upstreaming until we have extension maps? +Jordan: Needs talking about. +Myles: Do we need sugary defaults or not? I think it makes sense for loaders. There’s value in having ecosystem defaults, instead of a 100 different things. Do you assume extension maps will reach consensus? +Jordan: I am not saying we must ship extension maps. If we got consensus on an implementation, I would probably remove my objections so we could implement them after upstreaming. +Salah: You can’t offer time to implement, so assuming we say yes, there needs to be some willingness to implement in the group. Do we have capacity to implement this? +Jordan: I may have some time in a couple of months. Would be willing after that. +Guy: We hoped to move forward with upstreaming soon. We can change things later before unflagging. We have two blocks from Jordan: type flag and CJS extension. Should we vote or revert? +Rob: I’d be happy to vote. +Guy: How about we put in what we have, and we put in items to re-evaluate later? E.g. we can remove the documentation. Is there a middle ground? +Jordan: Yes, I would prefer to remove the documentation. There are already going to be massive renames. Tool configs will change. Renaming to .mjs is safe. Renaming to .cjs is not safe. We risk ecosystem churn whenever you blog. We have talked about minimal kernel to avoid bad signals. +Guy: Can we mark these explicitly as phase 3? Would it alleviate concerns? +Jordan: That would be an improvement, regardless. I would feel better if we got consensus on extension mapping. The loader we have does an extension map. It is minimal work. It won’t be time-consuming. We just need to decide what it needs to do. I don’t think it’s useful to have .mjs and.cjs files. +Myles: I am concerned about the patterns triggered by extension maps. The eventual implementation of loaders would be the extension maps. I am concerned about introducing extension maps too soon - it adds extra package lookups. It is additional work on a per-scope basis. I would like us to have as little in package.json as possible. “Type” is good - parallel with script tag. Loaders will have package.json impact. +Jordan: Extensions map alleviates most use of loaders. +Salah: That is not accurate. I experimented with that. +JDD: Should we vote? +Myles: I will not participate in a vote. +JDD: How do we call it? +Jordan: confirming that only allowing CJS is blocking upstreaming +JDD: I am calling the vote. Who is in favour of CJS moving forwards? ++1 means move forwards with .cjs +Results: + 4 in favour + 6 neutral + 1 against +Jordan: For anyone raising PRs, please actively seek objections to surface objections sooner rather than alter. +Geoffrey: I have seen a lot of objections recently of “I don’t like this” rather than constructive comments. + + +* Steps required to upstream implementation [#286](https://github.com/nodejs/modules/issues/286) + - 15 minute timebox +Myles: We need to add docs for phase 3 around type flag. Re-adding folder resolution. Have updated docs to reflect latest implementation. Geoffrey, is the docs ready? +Geoffrey: What are we doing about --type? Anything else that lands needs docs. It’s basically done. +Salah: Can we put a gist on the reliable way to use it? +Myles: I’ll put a test build there. +Geoffrey: I’ll add readme. +Myles: We have a blog post - 291. +Geoffrey: We need to vote if we capitalize the M in ES Module. It’s lowercase throughout Node docs. +(will talk about capitalization outside the meeting) +Salah: If you refer to a file, it’s ESM. +Myles: We now have LKGR. The only thing that will land is Guy refactoring, doc fixes, I will open PR containing this after the meeting. Objections on opening the PR to Node this week? NO OBJECTIONS! +Will open it today or tomorrow. +Myles: Jordan, I’m willing to work on the exports proposal. It’s coupled with loaders. + + + +* Announcement blog post [#291](https://github.com/nodejs/modules/pull/291) + - 10 minute timebox + +### Next Steps (15 minutes) + +Split time across the following topics if time permits. + +* Locking down the “process” and “Buffer” globals [#235](https://github.com/nodejs/modules/issues/235) + +Myles: Any objections? +Jordan: Yes, I object (to process, not Buffer) +Guy: It’s reserving design space. I don’t think it should go into LKGR. I just want support, or support that there won’t be objections. +Myles: We should talk about this at the next meeting. + +* CommonJS import interoperability decisions [#264](https://github.com/nodejs/modules/issues/264) + - Refs: + - Moving forward with Dynamic Modules? [#252](https://github.com/nodejs/modules/issues/252) + - Import named vs default from CommonJS packages [#260](https://github.com/nodejs/modules/issues/260) +* Proposal for dual ESM/CommonJS packages [#273](https://github.com/nodejs/modules/issues/273) + - Refs: + - Exports main [#41](https://github.com/nodejs/ecmascript-modules/pull/41) + + + +