Merge pull request #529 from nodejs/robpalme-patch-3

docs: Minutes for 2020-06-17

Author: robpalme

doc/meetings/2020-06-17.md

@@ -0,0 +1,71 @@
+# Node.js  Modules Team Meeting 2020-06-17
+
+## Links
+
+* **Recording**: http://www.youtube.com/watch?v=hFfwRkR-L-I
+* **GitHub Issue**: https://github.com/nodejs/modules/issues/528
+* **Minutes Google Doc**: https://docs.google.com/document/d/1FLK3nkCpxF6D-JFuoZlGpovF0lpSQ_8TP3wini6FsB0/edit
+
+## Present
+
+* Modules team: @nodejs/modules
+
+- Myles Borins (@MylesBorins)
+- Jordan Harband (@ljharb)
+- Darcy Clarke (@darcyclarke)
+- Rob Palmer (@robpalme)
+
+## Agenda
+
+## Announcements
+ 
+*Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
+
+### nodejs/node
+
+#### Special treatment for package.json resolution and exports? [#33460](https://github.com/nodejs/node/issues/33460)
+
+- MB: There are ways to get an entrypoint but it may not be the package root.  So heuristics may be needed to find package.json
+- JH: package.jsons can be copied so you can't know for sure.  API for bare-identifier to package.json provides a way for tools to work.
+- MB: We could publish an ecosystem package - find-package-json - would be siblings at the root of node_modules.  This matters when I want my dependency's package.json.  If that hierarchy is guaranteed, direct dependencies should be peers.
+- JH: Use-case is I'm a tool used in a project I don't control.  So answer won't be relative to the tool's location.
+- MB: So I'm a dependency of the project. Maybe I'm bundling.  Instrumented by the top-level package and I need to find other dependencies.  You need to set the root.
+- JH: You can put node_modules at the root of your disk.
+- MB: Everything is resolved to yourself.  If overlapping.
+- JH: Node already has the logic.  You don't know where your dependencies will come from.
+- MB: Why is this different to the root of your resolve?
+- JH: With exports, you can't know for sure.  Will show an example offline.
+- MB: Let's try the ecosystem package approach first.
+- JH: If it can 100% work in userland that's fine.
+- MB: Some people may want to prevent package.json leaking to users.  Or maybe if people are ok with it being public, we just change our defaults.
+- GB: Depends how many tools are impacted.  Softly feeling we don't need to do anything.
+- MB:  If exports is used to generate import maps, maybe package.json shouldn't be available.  It's easier to remember the rule that "only exports get exported".
+- JH: README can be used a hint.
+- GB: API to get package root would permit fs.readFile to grab package.json
+- MB: Not 100% but the basic algorithm to resolve the file and then crawl will probably always work.
+- JH: Babel has an option that duplicates package.json
+- GB: You don't look for package.json - you look for node_modules
+- MB: If we had module.resolve to give a path, with a changeable root, you could always go up to node_modules then back down.
+- JH: It's possible.  Resolve already needs to duplicate the whole algorithm.
+- MB: If we expose resolve, that gives you everything you need.  NODE_PATHS may confuse here.
+- JH: Even if it is doable in userland, it seems silly to not put it in Node.
+- MB: I think we need a meta-issue to discuss this.  Bring up a series of APIs at once.  Maybe we want to introduce a top-level resolve module.  My gut is that we don't need a new API for this.
+resolveType()  resolveRoot()  resolvePath().  resolveRoot() may be better because it is environment-agnostic.
+- JH: I remain convinced we should have a resolvePackageRoot() somewhere.
+- MB: Maybe a getPackageMetadata.  It could be synchronous.  There is a large cost to putting this API in core.
+
+
+#### module: CJS exports detection [#33416](https://github.com/nodejs/node/pull/33416)
+
+- GB: How do you define success?  Maybe not everything was intended to be exported.
+- MB: Maybe's there's a field in package.json to enable the heuristic?  Less work than writing a wrapper.
+- GB: We need to make it as good as possible then merge it in behind a flag to get feedback.
+- JH: People are going to want to use this on abandoned packages.  The heuristic is more likely to break due to a change in Babel that upsets the heuristic.
+- MB: User research may be good - but biased responses to "do you want exports for CommonJS if it works X% of the time?"
+- GB: Let's study guy's PR.
+- MB: Releasing under an experimental flag seems worth exploring.
+- GB: It uses a WASM library for parsing.
+- MB: Can we land it non-observable when the flag is off?  If so, let's do it.
+- RP: Do we have many people complaining about lack of named exports for CJS?
+- GB: Not really. A few issues.
+- MB: Adding this experimental flag is nice.  Combined with auto-extension flags, maybe that gives you the webpack experience as an opt-in mode.