Skip to content
This repository was archived by the owner on Sep 2, 2023. It is now read-only.

doc: 2019-01-16 notes #257

Merged
merged 1 commit into from
Feb 5, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 85 additions & 0 deletions doc/meetings/2019-01-16.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
# Node.js Foundation Modules Team Meeting 2019-01-16

* **Recording**: https://www.youtube.com/watch?v=miv2i1h5CM0
* **GitHub Issue**: https://github.com/nodejs/modules/issues/248
* **Minutes Google Doc**: https://docs.google.com/document/d/1JTNIz5XMoKKAxyKF4pC-GoK9Wy3ZUIF0EwsUezZ87L8/edit

## Present

- Myles Borins (@MylesBorins)
- Saleh Abdel Motaal (@SMotaal)
- Matt DuLeone (@mduleone)
- Jeremiah Senkpiel (@fishrock123)
- Gus Caplan (@devsnek)
- Rob Palmer (@robpalme)
- Guy Bedford (@guybedford)
- Wesley Wigham (@weswigham)
- Daniel Rosenwasser (@DanielRosenwasser)
- Geoffrey Booth (@GeoffreyBooth)
- Jordan Harband (@LJHarb)

## Agenda

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

### Updates (5 minute timebox)

* Structuring a "Breakout Teams" project board [#244](https://github.com/nodejs/modules/issues/244)
- 2 minute timebox

* Discussion: Organizing work [#230](https://github.com/nodejs/modules/issues/230)
- 3 minute timebox

Selah: it is up and ready to start being used. Needs groups to start using it.

### Approving PRs (5 minute timebox)

* doc: update stage 2 regarding dynamic modules [#242](https://github.com/nodejs/modules/pull/242)
- 5 minute timebox
- No objections!

### Discussion (40 minute timebox)

* Mode: esm proposal [#247](https://github.com/nodejs/modules/issues/247)
- 10 minute timebox
- Demo time!
- Started off with a minimal implementation with several proposals.
- Have a few edge cases with how they interact which we'll go over.
- This minimal implementation supports `.mjs`, and Node can run with that.
- Can also use CommonJS from a `.js` file from plain Node.
- And can also `import` from that CommonJS `.js` file!
- Note that
- the `.js` comes in with a `default`.
- have to use the fully-qualified name.
- Setting the `main` field in a `package.json` still resolves correctly when directing to a CommonJS, but has to be explicit with relative and extensionful paths when pointing to ESM.
- "Deep" imports from packages don't work - each package is totally encapsulated.
- New `exports` field - can forward deep paths within a package.
- We discussed treating all `.js` as ESM - here, to accomplish that, users have to select `mode: esm`.
- All this means you can use the `package.json` `main` field for CJS and `exports` for ESM, and you can have them both work simultaneously.
- You can also turn off the encapsulation behavior (unclear - how @guybedford?)
- Jordan: You have a really good case for the ergonomics of `"mode": "esm"`
- Guy: I don't care what it is as long as it takes 20 keystrokes or fewer
- In terms of the `exports` functionality, it might be a little difficult to make it apply to CommonJS
- Gus: Why is encapsulation the default in `"mode": "esm"`?
- Guy: `"exports"` is an encapsulation of what you get in the package.
- Gus: I have go to but I have concerns about this not including JavaScript inputs. We need something that gives people more freedom.
- Rob: feels like the "desired" way of using it and I wonder - \[\[background noise from siren]]
- Guy: Have to ensure that people who don't like encapsulation have a way out.
- Geoffrey: Would love to have people try this out to see what's confusing and get user feedback. Specifically, how the main, mode, and exports fields work together.

* Dynamic Modules Development in Node.js [#24894](https://github.com/nodejs/node/issues/24894)
- 10 minute timebox
- Without spec text there's really nothing we can do here.

* Specify import file specifier resolution proposal [#19](https://github.com/nodejs/ecmascript-modules/pull/19)
- 10 min

- If `"mode"` is the one thing that turns things on/off, then maybe `"exports"` shouldn't be the signifier for whether a package is ESM.
- Jordan: A map from files to parsing modes would probably be more general.
- Bradley: treating any one given circularity problem as "fatal" means you have to treat the whole system as fatal. We should avoid treating all circularities as fatal. Goto example is loader.js being loaded as CJS but making all .js files treated as ESM
- Myles: even if you just use strings for `mode`, you can always expand to mapping objects later on.
- Guy: if this is something we want to pursue, this is worth raising with npm given that it's focused around UX.

* \[Do not merge\] doc: Add pkg-exports proposal to resolve spec [#14](https://github.com/nodejs/ecmascript-modules/pull/14)
- 10 minute timebox
- Action item: create an issue for updating the exports spec to be applicable to the CJS goals