doc: june meetings

doc/meetings/2018-06-06.md

@@ -0,0 +1,53 @@
+# Node.js Foundation Modules Team Meeting 2018-06-06
+
+* **Recording**: https://www.youtube.com/watch?v=e8CovmklaKA
+* **GitHub Issue**:  https://github.com/nodejs/modules/issues/124
+* **Minutes Google Doc**: https://docs.google.com/document/d/1UKbxxr35YTlaiu6h6xYSCweWOhTZExLHPUJn8-tZSXs/edit
+
+## Present
+
+- @DanielRosenwasser (Daniel Rosenwasser)
+- @mduleone (Matt DuLeone)
+- @weswigham (Wesley Wigham)
+- @mhdawson (Michael Dawson)
+- @targos (Michaël Zasso)
+- @xtuc (Sven Sauleau)
+- @jdalton (John-David Dalton)
+- @bmeck (Bradley Farias)
+- @guybedford (Guy Bedford)
+- @GeoffreyBooth (Geoffrey Booth)
+- @giltayar (Gil Tayar)
+- @benjamn (Ben Newman)
+- @jankrems (Jan Krems)
+- @inidaname (Hassan Sani) 
+
+## Agenda
+
+Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
+
+### nodejs/node
+
+* loader: warn when the user imports a module with a thenable namespace [#20951](https://github.com/nodejs/node/pull/20951)
+
+### nodejs/modules
+
+* Thinking about deadlines [#123](https://github.com/nodejs/modules/issues/123)
+* Initiative: Terminology / Historical Decisions documents [#119](https://github.com/nodejs/modules/issues/119)
+* Feature: Transparent interoperability for ESM importing CommonJS [#100](https://github.com/nodejs/modules/issues/100)
+* transparent-or-not interop [#90](https://github.com/nodejs/modules/issues/90)
+
+* Developer Survey [#85](https://github.com/nodejs/modules/issues/85)
+  * request to put out developer survey to confirm what we believe developer
+  opinions are.
+* Use Cases (Tracking Issue) [#55](https://github.com/nodejs/modules/issues/55)
+
+## Notes
+
+The agenda comes from issues labelled with `modules-agenda` across **all of the repositories in the nodejs org**. Please label any additional issues that should be on the agenda before the meeting starts.
+
+## Joining the meeting
+
+* link for participants: Will be added a few minutes before meeting starts
+* For those who just want to watch:
+* youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled
+

doc/meetings/2018-06-20.md

@@ -0,0 +1,93 @@
+# Node.js Foundation Modules Team Meeting 2018-06-20
+
+* **Recording**: https://www.youtube.com/watch?v=RIdJMD42ZGs
+* **GitHub Issue**:  https://github.com/nodejs/modules/issues/124
+* **Minutes Google Doc**: https://docs.google.com/document/d/1UKbxxr35YTlaiu6h6xYSCweWOhTZExLHPUJn8-tZSXs/edit
+
+## Present
+
+- Michael Dawson (@mhdawson)
+- Daniel Rosenwasser (@DanielRosenwasser)
+- Jan Krems (@jkrems)
+- Wesley Wigham (@weswigham)
+- Myles Borins (@MylesBorins)
+- Matt DuLeone (@mduleone)
+- Gus Caplan (@devsnek)
+- John-David Dalton (@jdalton)
+- Gil Tayar (@giltayar)
+- Saleh Abdel Motaal (@smotaal)
+- Geoffrey Booth (@GeoffreyBooth)
+- Guy Bedford (@guybedford)
+- Michael Zasso (@targos)
+- Sven Sauleau (@xtuc)
+- Hassan Sani (@inidaname) 
+- Torgny Bjers (@tbjers)
+
+## Agenda
+
+This meeting is to discuss transparent interop with the goal of informing and coming to a decision on if-any-transparent interop should be possible _(by default, or by loader, or by otherwise)_. Please keep in mind transparent interop is a large umbrella. We should clarify and make clear distinctions about what we are discussing _(one sided, two sided, etc.)_.
+
+Other Items:
+
+* governance: s/pull request/issue for new members ([#128](https://github.com/nodejs/modules/pulls/128))
+* Pull request opened for import.meta.require on core ([#130](https://github.com/nodejs/modules/pulls/130))
+* Have presentation on loaders. ([#128](https://github.com/nodejs/modules/pulls/128))
+* Add features list to README ([#128](https://github.com/nodejs/modules/pulls/134))
+
+## Invited
+
+* Modules team: @nodejs/modules
+
+* We have quorum
+* Landed [#128](https://github.com/nodejs/modules/pulls/128) (landed)
+* Deferred discussing (#130) until the end of the meeting
+* Defer presentation on loaders ([#135](https://github.com/nodejs/modules/issues/135))
+* Add features list to README [#134](https://github.com/nodejs/modules/pulls/134) (landed)
+  - Used to close a large portion of the open feature issues and move them into a single place
+* Transparent interop discussion
+  - Jordan: The discussion of transparent interop often falls to (one-way: importing CJS in ESM) and discussing if it should support named exports by default or a loader.
+  - Jeremiah: Are we talking about resolving to ESM in `require` via promise?
+  - Jordan: Let’s defer that until we agree if `require` ESM is a thing we want to do
+  - Gil: We have `require` for ESM by way of dynamic import()
+  - Gil: I think we can’t have synchronous import via `require` since the current Node implementation is async and may lock-in to async with top-level await.
+  - Bradley: I like Jordan’s idea to defer talking about `require` and ESM
+  - Bradley: Must allow static import to load CJS for significant execution order (state, etc.)
+  - Myles: What are the goals of transparent interop? Bradley mentioned a goal of maintaining the ability to have execution order. Jordan has mentioned a goal that transitioning between ecosystems. Let’s brainstorm them. We can talk about the risks too.
+  - Wes: The ability to have some overlap between the APIs a CJS and ESM module can expose (Easier to migrate to ESM).
+  - Jeremiah: I would like to mitigate as much as possible either CJS or ESM being treated as second class to the other.
+  - Gil: Currently we can’t be truly transparent because named exports may change execution order
+  - Saleh: Some clarity on the migration. For example, are we shifting users from CJS to ESM? We should have a predictable path forward and clarity of milestones. I believe we should encourage users to migrate to ESM. 
+  - Bradley: I have to comments. RE Gil: I think named exports is an anti-goal. I want to defer named exports since it’s a breaking change.
+  - Guy: RE Gil: I don’t think it’s valid. It’s possible to have goals that are inconsistent with each other. It’s about trade-offs. Named exports and execution interleaving may work out. Do we have an update on execution order an named exports?
+  - Myles: Nothing to update on that front.
+  - Wes: 2nd’ing Bradley. With CJS -> default is a valid upgrade path, though the larger the overlap the easier the transition.
+  - Daniel: Users want an easy transition.
+  - Myles: I want to list some anti-goals.
+    - Confusing errors (named exports)
+    - Hard to teach
+    - We should be cautious introducing a goal that is not supported by the web by default
+  - Bradley: Clarify anti-goal, goal, pro/con.
+  - Jordan: +1 and expand on Guy, Wes, Bradley. When I say transparent interop I’m not talking about strict-transparent interop. For me default transparent interop is in service of transition. In 5-10yrs ESM is the default module system. Some level of transparent interop is valuable. Without it I fear people won’t migrate. I think the more we can make the transition smooth the better (for CJS and ESM users)
+  - Jeremiah: I’d like to add to add to the difficult to teach anti-goal. Having `require` return a promise would be confusing to new users.
+  - Gil: If we remove transparent interop then .mjs appeal is diminished
+  - Jordan: With or without transparent interop .mjs is required for ESM by default
+  - Gil: Making the transition from .js to .js is easier than .js to .mjs
+  - Jeremiah: Can we come to a shared understanding that perfect transparent interop is not possible? 
+  - Geoffrey: I would like to prioritize avoiding .mjs. We should discuss what the tradeoffs are for dropping it.
+  - Myles: One of the reasons we need .mjs is because there’s no in source way to detect it.
+  - Geoffrey: I understand that but the npm proposal shows we can have a way forward.
+  - Bradley: We should table the extension talk
+  - Guy: .mjs is useful to solve many transparent interop problems
+  - Jordan: Could we defer the extension so we can discuss do we want some level of transparent interop at all and if we want it by default
+  - Geoffrey: I like the loader centric approach to things presented by Myles. I think Node should ship ESM as the default and if you want to load CJS then you’d need to load a CJS loader (or various loaders to gauge the level of transparent interop). The basic CJS loader should be maintained by core. It’s a way of splitting the difference between supporting it by default and not having it in core.
+  - Bradley: I want to push the topic of loaders out (since we don’t know what they are). I want to raise a concern with the idea is that we ship only ESM in Node. If we migrate to ESM as the default that means no CJS files can be run. It’s a large breaking change so is a support burden.
+  - Geoffrey: This would only be if the entry point is ESM so the rest would be ESM and you’d need loaders to support CJS. If the entry is CJS then it would behave as it does today.
+  - Jan: As a quick note having a loader flag works OK if you have your average npm start server but doesn’t work well for CLI tools (!# arguments don’t work).
+  - Myles: Would dynamically be able to call loaders (at runtime) help?
+  - Jan: Yes.
+  - Myles: Is it too soon to dig into transparent interop until we define loaders better? 
+  - Bradley: I would discourage that approach. The ability of loaders is very limited. We should be careful loaders because we have to ship and support these things. Our default implementation should be suitable for the average user without loaders.
+  - Kevin: Goal 1: A choice of module system of a package does not enforce a choice of module system on another package. Goal 2: We need to not require a package author ship 2 versions of their code.
+  - Myles: Next meeting we should start with loaders for the first half and then interop for the second.
+  - Geoffrey: Can we also talk about the implementations forks are working on?
+  - Myles: Yep! The agenda is editable.