Skip to content

Commit

Permalink
doc: 2019-03-27 notes
Browse files Browse the repository at this point in the history
  • Loading branch information
MylesBorins committed Apr 10, 2019
1 parent e3312e7 commit 026fe73
Showing 1 changed file with 100 additions and 0 deletions.
100 changes: 100 additions & 0 deletions doc/meetings/2019-03-27.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
# Node.js Foundation Modules Team Meeting 2019-03-27

* **Recording**: https://www.youtube.com/watch?v=rz6KhC9t_pQ
* **GitHub Issue**: https://github.com/nodejs/modules/issues/302
* **Minutes Google Doc**: https://docs.google.com/document/d/1D4Wf27NoMoFuL02wYcYO1Iy1k0pOT0XeTa2OZAkbPQo/edit

## Present

- Myles Borins (@MylesBorins)
- Jordan Harband (@ljharb)
- Daniel Rosenwasser (@DanielRosenwasser)
- Rob Palmer (@robpalme)
- Michael Zasso (@targos)
- Wes Wigham (@weswigham)
- Saleh Abdel Motaal (@SMotaal)
- Geoffrey Booth
- Hassan Sani
- Ryan Day (@soldair)
- Guy Bedford
- Jeremiah Senkpiel (@Fishrock123)
- Gus Caplan (@devsnek)

## Agenda

Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.

### Review Upstream Changes

* upstream objection to --type [#296](https://github.com/nodejs/modules/issues/296)
- changed to --entry-type (no recursive changes)
- CONCLUSION: No objections
* upstream objection to -m [#295](https://github.com/nodejs/modules/issues/295)
- Removed from current implementation
- CONCLUSION: No objections

* Rename errType mismatch
- Jordan: We can make this change in future

### Landing Upstream Implementation

* Tracking upstream PR [#64](https://github.com/nodejs/ecmascript-modules/issues/64)
- Myles: Folded 40 commits to 10 commits to ease reviewing, today folded into 1 commit. Refers to input PRs. Includes co-authors: Guy, Myles, JDD, Evan, Geoffrey, MichaelZ. Has 7 approvals.
- CONCLUSION: No objections to landing on master!
* extreme whooping and applause *
* Later: Myles prepares to land the PR *
- Michael: Should we backport to Node 11?
- Myles: Let's wait one release.
- Jordan: It's good to wait.
* Myles observes lots of green tick checks *
* All 4 people in the room press the merge button: PR is now landed! *
* Even greater whoops of joy *


### Next Steps

* What's next for the team?
- Moratorium: Propose we drop it. Myles pledges not to allow big changes without consulting the modules team.
- Jordan: Maybe have a policy for major/minor changes?
- Myles: The team has had friction. What is our role/expectations?
- Gus: It would be more efficient if we just moved to core and iterate there. Should be working more closely with the collaborators there.
- Jordan: That's just the github repo choice. It would be ideal for the modules team had to approve of changes.
- Myles: We need to be chartered to do that. We are not chartered.
- Jordan: Can we pretend? We represent various constituents. That usually represents a larger group, so the feedback is useful. It would be a loss if this group did not continue to contribute those perspectives, regardless of charter. Last meeting suggested we need adjustments. We should try that before altering the venue.
- Geoffrey: This group adds value debating design decisions. Throwing PRs at core might not consider our design parameters. How can we limit the scope of PRs allowed in?
- Myles: Looking in modules repo today. Our governance says "consensus seeking process, merging PRs here, not NodeJS core". Not bug fixes. Not error message changes. I suggest removing the NodeJS bit, pare down the exemptions, what we work on. The request could be a moratorium to not stray from the phases doc. Could be more explicit: please don't land things relating to the needs-consensus things in our doc. Members with commit bits can put red crosses on PRs that violate this.
- Jeremiah: Node core can't own a subsystem in that way. WGs can do this kinda. People will respect people that come with PRs and talk about things.
- Salah: I second Geoffrey's idea. Having the group so far has allowed insight into relevant activities in core. This group brought them to our attention. That distillation is good to keep. Concerned about not having this.
- Myles: Core works by triaging and then adding the teams that are experts. Highly unlikely for something to go through on ESM that would not @ modules. Controversial things would put a clear red x for items we need to discuss. This applies to things that are not working groups, e.g. inspector that has 5 members. The difference is that things can be landed without a meeting.
- Saleh: What do we need to do to be chartered?
- Myles: To be blunt, I need to be convinced and am not currently convinced. Apologies. Maybe re-examining our governance. One idea is "rough consensus" instead of "full consensus". All groups have this problem. Could even take it to core or other venues if the model works. I want to be so proud of our work that we offer it to other groups. I can have a go modifying our governance document. Modules is a hard domain - lots of things trigger relitigation of other areas. Maybe we are stewards of the roadmap.
- Jordan: Low level C++ implementation is the Node core group. But user-observable things is the modules group should steward.
- Myles: I am comfortable with this. Would anyone like to update the governance doc? (updating to reflect non-moratorium, change of scope). I will do it! And I feel positive about it.
- Saleh: I will help iterate with you.



* Locking down the "process" and "Buffer" globals [#235](https://github.com/nodejs/modules/issues/235)
- PR on Node core to deprecate these inside ESM only. Made them getters first. Introduced it at SES. Mark Miller verified it. Will update the PR over the next few months.
- Myles: Canary in the Gold Mine looks ok with this. Breakages are the same as Node 12. We have made major change before that turned out to be mistakes. They can be reverted in a patch if the change is found to be destructive. 100+ modules say this change is safe. So we can only find out the impact by releasing.
- Jordan: I think Buffer deprecation is fine. Very concerned about "process". It's fine to remove the unsafe parts, but it's hard to do them individually, so we remove it fully. process is used for environment detection. I once broke Yahoo.com. So worried about this. Keeping process out of ESM for now, would be fine. It would be wiser to keep process global, but eliminate the dangerous parts. The PR now is fine. Please can everyone consider the impacts.
- Guy: The getter PR is already merged to master. Adding a global is a very different thing. Websites have strong backwards compatibility concerns. No code is depending on this change. The new process can just have bare minimum. Or import.meta.platform. We accept that some things will hit people, like the package.json module field - this might be one of them.
- Salah: This group needs syntax detection of node without relying on process. typeof(process). ESM code relying on this must be behind a flag, if it exists today.

* Moving forward with Dynamic Modules? [#252](https://github.com/nodejs/modules/issues/252)


* Exports main [#41](https://github.com/nodejs/ecmascript-modules/pull/41)


* esm: scoped --type, cpp refactoring (This is package vs entry) [#57](https://github.com/nodejs/ecmascript-modules/pull/57)


* Flags functionality options [#300](https://github.com/nodejs/modules/issues/300)


* Proposal for dual ESM/CommonJS packages [#273](https://github.com/nodejs/modules/issues/273)


* Warn about `--type` with shebang [#37](https://github.com/nodejs/ecmascript-modules/pull/37)

0 comments on commit 026fe73

Please sign in to comment.