From 1ef8748effd975c8ea8557db6fc061b235290bfa Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 29 Aug 2019 15:41:48 -0400 Subject: [PATCH 1/3] doc: august meeting notes Refs: https://github.com/nodejs/modules/issues/370 Refs: https://github.com/nodejs/modules/issues/376 --- doc/meetings/2019-08-14.md | 104 +++++++++++++++++++++ doc/meetings/2019-08-28.md | 183 +++++++++++++++++++++++++++++++++++++ 2 files changed, 287 insertions(+) create mode 100644 doc/meetings/2019-08-14.md create mode 100644 doc/meetings/2019-08-28.md diff --git a/doc/meetings/2019-08-14.md b/doc/meetings/2019-08-14.md new file mode 100644 index 0000000..26e7c1b --- /dev/null +++ b/doc/meetings/2019-08-14.md @@ -0,0 +1,104 @@ +# Node.js Foundation Modules Team Meeting 2019-08-14 + +## Links + +* **Recording**: https://www.youtube.com/watch?v=OEFVWjpkbao +* **GitHub Issue**: https://github.com/nodejs/modules/issues/370 +* **Minutes Google Doc**: https://docs.google.com/document/d/1Ng0-0Mp34z2gAqkDsyWsZkFK6XUIrgsyA3lv8i4917U/edit + +## Present + +* Myles Borins (@MylesBorins) +* Gus Caplan (@devsnek) +* Jordan Harband (@ljharb) +* Jan Krems (@jankrems) +* Saleh Abdel Motaal (@SMotaal) +* Bradley Farias (@bmeck) +* Alex Aubuchon(@A-lxe) +* Geoffrey Booth (@GeoffreyBooth) +* Guy Bedford (@guybedford) +* Daniel (@???) +* Darcy Clarke (@darcyclarke) + +## Agenda + +## Announcements + +*Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/node + +* esm: support loading data: URLs [#28614](https://github.com/nodejs/node/pull/28614) + +Bradley: We talked about data URLs last week. No objections on the PR right now, no quorum, no moratorium. Can we go ahead with this? +Myles: I think we're good to move forward +Jordan: This feels like something that will be abused more than used, and the benefits are minimal compared to the risks. Justification seems to be "the web did it so we should too" which doesn't sound sufficient to me. I'm not clear on what the use cases are when you have a filesystem, unlike the web where you don't have a place to make a temp file on the fly. +Bradley: We have a few use cases in the PR. Particularly when you don't have write access to the file system. +Myles: On GCP we don't offer file system access -- none at all after build. +Saleh: It's useful to see the use cases, and so as long as it's flagged, we can see use cases. Also, cross node/web functionality allows for more consistency between solutions (ie loaders). Node currently forces you to write virtual modules to disk. +Jan: I talked with somebody yesterday about on-the-fly content generation, and they cannot rely on disk (security concerned, can't trust file system writes). At groupon the temp directory was not guaranteeable across environments. +Jordan: Ok so even if all these use cases *can* be done with the filesystem, the filesystem isn't always available, so data urls become necessary. +Geoffrey: For security concerns, you might want to avoid writing to the file system as that exposes it to disk issues, other processes looking at it. +Bradley: I think we should avoid security concerns as they're difficult to puzzle around given Specter. +Jordan: @jan commonjs requires the filesystem? +Jan: The require system is open to all things, so you can generate a module from string. +Jordan: Are there plans to add data URIs to cjs? +Jan+bradley: No because you can do it anyways, and also the cjs specifier system doesn't work well with URIs. +Myles: Taking a step back, we have an upstream PR, but no upstream objections. Are there any? +Bradley: It sounds like we should keep data uris behind a flag +Jordan: I think it should be behind the experimental modules flag -- it would be a waste of effort to make a new flag right now. +Myles: I don't think we need a flag, but it's not much work to add one. It would be weird to not have a flag and add one later, so if that's the plan start with it. I prefer no flag though. +Jordan: I'm not fully in favor of data uris, but I do not want to obstruct the PR. +Myles: How about we merge it, and then Jordan opens a revert PR arguing why. +Jordan: Give me a week or two to consider if the revert is needed, but SGTM + +### nodejs/modules + +* Validate exports keys and values [#359](https://github.com/nodejs/modules/issues/359) + +Jan: Landed already + +* Package Exports [#341](https://github.com/nodejs/modules/issues/341) + +Jan: made a lot of progress implementing exports, behind an additional flag automatically enabled if using --experimental-modules. Progress board exists. Implementation supports most of the proposal. `.` "main" discussion ongoing. Import map names still being discussed as well. Would like to gather consensus on those before unflagging. +Jordan: Would love to see this land in CJS, tons of uses. +Myles: would this be moved out of experimental if unflagged or stay experimental. Prior art allows us to unflag while keeping experimental. +Jordan: If we are unflagging it, it should be considered stable. That is when people can use it reliably without opting in. Stable enough to risk no further changes possible. +Saleh: exports written for CJS. even if ESM is flagged would this be available in CJS without a flag? +Jordan: yes +Jan: After unflagging exports should remain experimental potentially because it has ecosystem effects. Important to get feedback from other environments like bundlers as ecosystem support is picked up/considered. As ecosystem adopts, changes may need to occur with care. +Myles: we can keep the console warning even without the flag when it is used. I am comfortable calling things stable even with these warnings. +Jordan: I was mostly talking about unflagging ESM, unflagging exports is not as much a concern. When unflagged ESM will be risking things being kept as-is. We can prepare the ecosystem for unflagging by adding lint rules and support to 3rd party resolvers. +Myles: the stability being experimental allows smaller edge cases like error codes to be changed without a semver major. +Jordan: since exports affects 3rd party code, the warning would be coming from 3rd party module installation. +Jan: minor issue with exports is that it cannot be unit tested by the package itself. This should be fixed. +Jordan: this is a problem in general of "testing your package as if it were published". +Myles: loading via relative specifiers inside the module is inconsistent vs "exports" +Jan: See "imports" proposal from guy for internal aliasing. +… talking about using ~ to get current package ... +Jordan: might want to enforce ~ going through exports. E.g. package.json#"files" is dangerous because forgetting to add files to the whitelist. +Myles: seems like we are ok with "exports", flag removed separately from ESM. We should identify a new feature/propose something for ~ which we talked about. Should we sync/move package name proposal from seeking consensus to implementing? + +* Loader Hooks [#351](https://github.com/nodejs/modules/issues/351) + +Brad: Lots of comments in design doc + github. Adding success criteria to examples. Need to sync up on changing the hooks themselves. Lots of suggestions and different directions. General feeling that we should split up the hooks somewhat. A few ideas on what the divide to be. Fairly consistent feeling that resolve return location and a seperate fetch hook that turns a module record or resource for module record is an approach being talked about. Figuring out how to split that and start moving. + +Still questions about how loaders should defined their format. Design document has a mime for determine format. Current loader is using a string enum. Contention on which approach should be used. Likely something we need to reach consensus within the committee. Don’t have quorum, so perhaps we need to talk about it again. Good thing to start talking about. + +Guy: Thread on loader discussion looks [?]. Lots of agreement on things, not much contention. Biggest thing for a usability perspective is separating the hooks. Happy to see we can look at the design. Mostly usability concern regarding mimes, but it might be superficial. A little bit concerned we don’t have a mime type for a node builtin, or what a .node file would be. So we need to come up with something for those cases. + +Brad; we have “application/node” for cjs. We tried to standardize something for C++ modules but it was rejected as they don’t have a well defined format. Could look at vendor track rather than standards… just need to agree with what to call them. + +Guy: I’m completely happy to go with mimes, no problem moving forward with that. + +Brad: Working on the way to have composed instrumentation of builtins. Added example but it may not cover all examples of what people can do. Basically the contrived example is adding to instrumentations to fs.readFileSync. Adding a console.time and console.endtime to it. If you have two loaders doing this it is hard to build right now, need more design work on this. Guy showed an idea of using import.meta to pre-inject other module namespaces so they can be used without a lot of redirection or source code rewriting. This is one of the harder solves + +Another built in experiment we have is the null loader. A loader that doesn’t load something. Example preventing loading fs. Synthetic module loader is another example, something created from memory. A transpiler loader, success criteria includes having a custom format sent through the pipeline. You need to implement regular expression modules. + +Are there specific use cases we need to have? + +Geoff: glancing at design doc for first time and I see the new examples at the end. When ready would love to see an example of DX. I see code but where do I put it? How do I let node know to use the loader? How do I create / use a loader? + +Alex: @Geoff the --loader api is the same as the way cjs loaders are currently loaded with --require, so we can look towards them for usability. One difference is that with cjs, loaders can often also be loaded in the middle of runtime with require(...), which we are not allowing for esm loaders due to security, predictability concerns. + +A use case I haven't seen considered is that of loading a v8 compile cache (https://github.com/zertosh/v8-compile-cache). The current proposal does not support dynamic instantiation of modules (only returning their content so that node can do the instantiation). Given that, the only way I can see supporting compile cache is by adding a compile cache content format that node supports. This is outside the realm of loader hooks, but should be kept in mind. diff --git a/doc/meetings/2019-08-28.md b/doc/meetings/2019-08-28.md new file mode 100644 index 0000000..f6b6265 --- /dev/null +++ b/doc/meetings/2019-08-28.md @@ -0,0 +1,183 @@ +# Node.js Foundation Modules Team Meeting 2019-08-28 + +## Links + +* **Recording**: https://www.youtube.com/watch?v=OBoGjhmz7jk +* **GitHub Issue**: https://github.com/nodejs/modules/issues/376 +* **Minutes Google Doc**: https://docs.google.com/document/d/1wN0J6PuUUjNli3BzzroJ2goljYtfvXOmKuYL_Xf1SAQ + +## Present + +* Modules team: @nodejs/modules +* Jan Krems (@jkrems) +* Wesley Wigham (@weswigham) +* Myles Borins (@Mylesborins) +* Saleh Abdel Motaal (@SMotaal) +* Guy Bedford (@guybedford) +* Darcy Clarke (@darcyclarke) +* Rob Palmer (@robpalme) +* Jordan Harband (@ljharb) +* Gus Caplan (@devsnek) +* Hassan Sani (@inidaname) +* Geoffrey Booth (@GeoffreyBooth) +* Jeremiah Senkpiel (@Fishrock123) +* John-David Dalton (@jdalton) + +## Agenda + +## Announcements + +*Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/modules + +* Divergent specifier hazard [#371](https://github.com/nodejs/modules/issues/371) + +GCB: When I was working on the attempt to try to get dual packages (the same package that contains both CJS and ESM sources being able to do require(pkg) as well as import(pkg) and it works in both cases). The user has to write require(pkg/cjs) import(pkg/esm). So we didn’t want to have two specifiers. If we have one specifier mean two different things in the two module systems this can cause chaos. And this has already come up in the GraphQL project where they adopted mjs under the previous --experimental-modules. I didn’t fully understand the issue so I dug into it a bit and tried to come up with a minimal repo of what the issue was. My sense was that this isn’t just a dual package thing but would also apply to extension searching, file.js and file.mjs having import ‘./file’ and require(‘./file’) resolving to two different things is basically the same issue. We basically have three options - (1) what we have now, (2) allow a hazard and document it properly or (3) come up with some clever solution to avoid the problem. The best one we have at the moment that came up in the thread is to have require support requiring esm, so that both would get esm sources resolving the issue. There’s a lot of issues separately with getting require(esm) to work. + +JHB: The hazard you are describing is one that has always existed in npm, not just because of extension searching but also because of package duplication which is a common thing in package ecosystems. The solution to this is peer dependencies which ensure there is only one copy in the tree. This is not something that can be fixed by leaving things as they are. If you use that solution then extension searching and dual packages offer no additional hazards. For me I have not seen any examples of a case that differs from that, so this hazard should not be relevant to discussing dual packages or extension searching. My understanding of the graphQL issue was having one in CJS and one in ESM. + +JK: I think it is skipping over some finer details to say that this is nothing new. Peer dependencies cannot save you from this assuming people are publishing packages that have both which is the only scenario that is actually a thing. Even if you only have a single copy of the package, because dynamic resolution applies you may find that you have two copies of the same module implementation within that same package. So there are ways to handle it by having specific files not specifically duplicated within the package. If you only transpile parts of the package and then have to manually maintain those parts of the package is definitely not something that the ecosystem is used to. + +JHB: That is fair thank you Jan. + +WW: I agree that the hazard exists, however the current tooling and recommended practices for working with CJS and ESM involve shipping both versions side-by-side. And changing peoples views on that is a monumental task. + +Going back to what Geoffrey was saying. We don’t actually need full require of ESM. All you need to say is that the ESM resolver is a strict subset of the CJS resolver. So that CJS would do everything that the ESM would do. If the result is something that should have been loaded as an ESM file, the CJS resolver can simply say no and throw. That’s all you need to do. You just need to be able to know that you should not load the thing. Actually being able to load it would be a nice enhancement on top of that but that’s not actually the thing that resolves the problem. + +JK: I assume that this implies ESM would never apply .mjs, or if it would it would do it with a lower priority than existing things. Otherwise it could never actually do it without stopping to be a subset of the CJS resolution. + +WW: The idea is that the ESM resolver today sees mjs as needing to have the exact extensions. Yes, if there is extension searching it must be the same. But the priority can be changed in both at the same time with something like the type: module field. + +MB: I want to step back a bit. Why Geoff brought this up was to look at why we don’t want to have extension resolution on by default, which does protect this hazard. To Jordan’s point, this hazard does exist to some extent within the ecosystem and is why npm started flattening dependencies specifically to minimize when this hazard would hit. And in my own personal experience when this hazard does hit it hits in ways that aren’t very intuitive. In order to understand what exactly is happening requires a somewhat sophisticated understanding of the Node.js module system. I don’t find that a compelling reason for us not to try and minimize the hazard in our own runtime. We’ve pointed this out as one reason for not having default file extension resolution, compatibility with import maps being another. Stepping back, the intention of opening this issue was to maybe close the discussion as to turning off extension resolution by default. If we want to discuss major changes for how we do things maybe that should be another discussion. + +GCB: To clarify it was actually to close the discussion around dual packages, but that was more of a side effect. + +MB: So you would like to remove extension searching as one of the cases that we are trying to solve for with our implementation? + +GCB: It would be moved down into the tabled area of phase 3 where we are not going to pursue this further. The only way I see we can avoid that happening is the require(esm) solution. If that PR comes up in a month, two months, even after we unflag it could be unflagged. + +WW: First of all, extension resolution, while it increases the surface area of this hazard, is not the only way this hazard surfaces. Anywhere the resolvers do things differently - ie in the interpretation of package.json flags. They should not be different resolvers, and the fact that they are different is the core of the problem. We just need to be able to guarantee that the one resolver always behaves as a subset of the other that is all. We’ve made this harder implementing the ESM resolver in C++ thinking that was a good idea, but if we were willing to just go back on that for a moment, then that would actually entirely solve this problem. Because both resolvers know about extensions, type: module etc. So the ESM resolutions can throw in CJS. And ESM can load CJS fine. + +JHB: Although I have many feelings about dual packages and extension searching, the thing I think is really critical is solving the problem of how I can publish a module that can work at least across Node versions - that is across the barrier between supports ESM and does not. If dual packages or extension searching isn’t the answer then fine let's find another answer. + +Anything that requires to write prose to explain it is just a massive failure in my opinion in providing compatibility and interoperability. + + +JK: ESM resolver is currently a subset of CJS. Anything that is not is a bug. The intention is for it to be a subset. A shared implementation might help guarantee that. But my attempts at sharing were not maintainable. Changing the CJS resolver is hard. I favour using a test suite to achieve compatibility. + +WW: We added exports to both. The CJS resolve doesn't understand type:module - that's the big bug in the current implementation. + +JK: After fixing this bug, we no longer face divergent specifiers. + +WW: If we start with the subsetting, we can add extension searching, then add require(ESM). That is incremental. + +Guy: But extension searching does not change the argument. + +WW: Divergent specifiers does not imply no extension searching. + +JK: This is about a specific form of searching - prioritizing mjs. + +WW: type:module lets you opt in to the change in priority. + +MB: The order of extension searching for CJS and ESM should be the same, and should switch based on type:module, means you can't just drop the extension to customize resolution behavior for each system. + +WW: ESM would need to respect require.extensions. + +JK: We are trying to get rid of that. + +WW: We could try to remove require.extensions from both systems. + + + +Guy: If you try to require(ESM) you would get an error. + +MB: If your "main" is extensionless, it resolves based on "type":"module". This solves a case. + +Guy: ESM files loaded by the CJS system must throw. + +MB: CONCLUSION: We will make the CJS resolver respect "type":"module", and extension searching order must be the same between both implementations. + +WW: The upgrade path is currently garbage. + +MB: Maybe we can target synchronous require in Node 14 as an incremental enhancement. Node 12 would cause breaking changes. + +WW: We just have to make things throw now. + +GB: We're not going to to implement dual packages before unflagging. + +JHB: I don't think we should do that. + +MB: We're at an impasse. Do you have an alternative proposal, Jordan? + +JHB: No. I would like an explanation of how to write a package in Node 12 LTS that works in 8, 12 non-LTS, and 12 LTS without forcing "await import()". + +GB: The only solution we have is the as-is. + +JHB: But this requires reading documentation. I rarely read readmes. + +JK: We know specifiers won't be modified, and tooling does not rewrite these for intermediate packages. We need to write that guidance. + +GB: Shall we put the migration guide on the roadmap? Do we defer dual-mode? + +JHB: Let's do the migration guide first. + +MB: It's not reasonable to block unflagging without proposing an alternative solution. + +JHB: Lots of people have blocked things. + +MB: This is different. + +ACTION: TLA in CJS? +ACTION: Migration guide + +* Revisit dot-main in exports field [#368](https://github.com/nodejs/modules/issues/368) + +JK: Exports originally had a dot main as a way to drop using main as one field for both. In the very first version there was even a shorthand where if you set exports to a string that would be the main. We dropped that (a) because of the dual package thing, and (b) dot main happened to be somewhat contentious as a way of having a key that was just a dot. But now that we have additional syntax in exports such as the array fallback syntax, we basically come to a choice between two semi-bad options. (1) bring it back - exports can override main completely both for CJS and ESM. or (2) we could support that same array syntax in main but that would mean that if you want to use fallbacks for your main export you would need to drop support for all bundlers before it was introduced. + +My thinking is that it is best to go with dot main. + +MB: Is the fallbacks support already supported in the implementation? + +JK: It is already supported - the fallback takes the first thing it understands, the first URL. So the current implementation does support it. And if we want to support it at anytime in future we do need to support it right now as the point of fallbacks is being able to have support for older versions. + +MB: If we have an array, and the first is ESM and the second is a CJS, and you have two parts in your tree. One imports the ESM then CJS and the CJS uses the same specifier? + +JK: Valid URLs will be taken. If it does not exist, it throws. + +MB: It fails based on invalid URLs. + +Guy: We could say only standard modules go through existence checks. + +MB: So main cannot be used for dual modules. It will just fail in the require loader. + +JK: Resolution is 100% repeatable. + +MB: I like this idea. We're not deprecating, but it shadows it. In a Node that supports exports, it's used. And "main" is the backwards compatibility hook. So for Wes/Jordan, this could be the solution we talk about for older version of Node. So you can transpile ES5/ES3 and use it as main. + +JK: The danger is that you have a package working on Node 10, then you upgrade and suddenly your app breaks because you were using require(). Having both fields makes this dangerous. + +MB: I will chew on it. Are there concerns if we open a PR? + +JS: This is a complicated discussion. + +GB: This would be a great feature. The upgrade process is tough. It would be a huge win to have environment-specific fields. + +MB: Hazard could be solved by best practice, e.g. console.log("you are using a legacy interface") + +GB: Downgrading the dependency would solve this. + +MB: We could have a mode:legacy that ignores exports and just uses "main". An opt-out could be sufficient to solve this. + +Guy: I think it could be worthwhile bikeshedding a name for this. + +JK: Yes. For the key name and the key location. I like the string|array possibility. + +MB: Agreed. Enables simplicity. + +* Loader Hooks [#351](https://github.com/nodejs/modules/issues/351) +* Package Exports [#341](https://github.com/nodejs/modules/issues/341) +* Proposal: Support loading package by own "name" [#306](https://github.com/nodejs/modules/issues/306) + + + From 9952587a651890e18f55ebb6f84f6596693a0413 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Sun, 8 Sep 2019 17:32:41 -0700 Subject: [PATCH 2/3] doc: fix formatting --- doc/meetings/2019-08-14.md | 44 ++++++++++++++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 4 deletions(-) diff --git a/doc/meetings/2019-08-14.md b/doc/meetings/2019-08-14.md index 26e7c1b..53d8406 100644 --- a/doc/meetings/2019-08-14.md +++ b/doc/meetings/2019-08-14.md @@ -23,7 +23,7 @@ ## Agenda ## Announcements - + *Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. ### nodejs/node @@ -31,25 +31,45 @@ * esm: support loading data: URLs [#28614](https://github.com/nodejs/node/pull/28614) Bradley: We talked about data URLs last week. No objections on the PR right now, no quorum, no moratorium. Can we go ahead with this? + Myles: I think we're good to move forward -Jordan: This feels like something that will be abused more than used, and the benefits are minimal compared to the risks. Justification seems to be "the web did it so we should too" which doesn't sound sufficient to me. I'm not clear on what the use cases are when you have a filesystem, unlike the web where you don't have a place to make a temp file on the fly. + +Jordan: This feels like something that will be abused more than used, and the benefits are minimal compared to the risks. Justification seems to be "the web did it so we should too" which doesn't sound sufficient to me. I'm not clear on what the use cases are when you have a filesystem, unlike the web where you don't have a place to make a temp file on the fly. + Bradley: We have a few use cases in the PR. Particularly when you don't have write access to the file system. + Myles: On GCP we don't offer file system access -- none at all after build. + Saleh: It's useful to see the use cases, and so as long as it's flagged, we can see use cases. Also, cross node/web functionality allows for more consistency between solutions (ie loaders). Node currently forces you to write virtual modules to disk. + Jan: I talked with somebody yesterday about on-the-fly content generation, and they cannot rely on disk (security concerned, can't trust file system writes). At groupon the temp directory was not guaranteeable across environments. + Jordan: Ok so even if all these use cases *can* be done with the filesystem, the filesystem isn't always available, so data urls become necessary. + Geoffrey: For security concerns, you might want to avoid writing to the file system as that exposes it to disk issues, other processes looking at it. + Bradley: I think we should avoid security concerns as they're difficult to puzzle around given Specter. + Jordan: @jan commonjs requires the filesystem? -Jan: The require system is open to all things, so you can generate a module from string. -Jordan: Are there plans to add data URIs to cjs? + +Jan: The require system is open to all things, so you can generate a module from string. + +Jordan: Are there plans to add data URIs to cjs? + Jan+bradley: No because you can do it anyways, and also the cjs specifier system doesn't work well with URIs. + Myles: Taking a step back, we have an upstream PR, but no upstream objections. Are there any? + Bradley: It sounds like we should keep data uris behind a flag + Jordan: I think it should be behind the experimental modules flag -- it would be a waste of effort to make a new flag right now. + Myles: I don't think we need a flag, but it's not much work to add one. It would be weird to not have a flag and add one later, so if that's the plan start with it. I prefer no flag though. + Jordan: I'm not fully in favor of data uris, but I do not want to obstruct the PR. + Myles: How about we merge it, and then Jordan opens a revert PR arguing why. + Jordan: Give me a week or two to consider if the revert is needed, but SGTM ### nodejs/modules @@ -61,22 +81,38 @@ Jan: Landed already * Package Exports [#341](https://github.com/nodejs/modules/issues/341) Jan: made a lot of progress implementing exports, behind an additional flag automatically enabled if using --experimental-modules. Progress board exists. Implementation supports most of the proposal. `.` "main" discussion ongoing. Import map names still being discussed as well. Would like to gather consensus on those before unflagging. + Jordan: Would love to see this land in CJS, tons of uses. + Myles: would this be moved out of experimental if unflagged or stay experimental. Prior art allows us to unflag while keeping experimental. + Jordan: If we are unflagging it, it should be considered stable. That is when people can use it reliably without opting in. Stable enough to risk no further changes possible. + Saleh: exports written for CJS. even if ESM is flagged would this be available in CJS without a flag? + Jordan: yes + Jan: After unflagging exports should remain experimental potentially because it has ecosystem effects. Important to get feedback from other environments like bundlers as ecosystem support is picked up/considered. As ecosystem adopts, changes may need to occur with care. + Myles: we can keep the console warning even without the flag when it is used. I am comfortable calling things stable even with these warnings. + Jordan: I was mostly talking about unflagging ESM, unflagging exports is not as much a concern. When unflagged ESM will be risking things being kept as-is. We can prepare the ecosystem for unflagging by adding lint rules and support to 3rd party resolvers. + Myles: the stability being experimental allows smaller edge cases like error codes to be changed without a semver major. + Jordan: since exports affects 3rd party code, the warning would be coming from 3rd party module installation. + Jan: minor issue with exports is that it cannot be unit tested by the package itself. This should be fixed. + Jordan: this is a problem in general of "testing your package as if it were published". + Myles: loading via relative specifiers inside the module is inconsistent vs "exports" + Jan: See "imports" proposal from guy for internal aliasing. … talking about using ~ to get current package ... + Jordan: might want to enforce ~ going through exports. E.g. package.json#"files" is dangerous because forgetting to add files to the whitelist. + Myles: seems like we are ok with "exports", flag removed separately from ESM. We should identify a new feature/propose something for ~ which we talked about. Should we sync/move package name proposal from seeking consensus to implementing? * Loader Hooks [#351](https://github.com/nodejs/modules/issues/351) From 623bf8bde27f7df6eddf6b0674809b00c052487d Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Sun, 8 Sep 2019 17:34:55 -0700 Subject: [PATCH 3/3] doc: add decision --- doc/meetings/2019-08-28.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/meetings/2019-08-28.md b/doc/meetings/2019-08-28.md index f6b6265..d117e3a 100644 --- a/doc/meetings/2019-08-28.md +++ b/doc/meetings/2019-08-28.md @@ -26,7 +26,7 @@ ## Agenda ## Announcements - + *Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. ### nodejs/modules @@ -68,7 +68,7 @@ JK: ESM resolver is currently a subset of CJS. Anything that is not is a bug. WW: We added exports to both. The CJS resolve doesn't understand type:module - that's the big bug in the current implementation. -JK: After fixing this bug, we no longer face divergent specifiers. +JK: After fixing this bug, we no longer face divergent specifiers. WW: If we start with the subsetting, we can add extension searching, then add require(ESM). That is incremental. @@ -110,7 +110,7 @@ JHB: I don't think we should do that. MB: We're at an impasse. Do you have an alternative proposal, Jordan? -JHB: No. I would like an explanation of how to write a package in Node 12 LTS that works in 8, 12 non-LTS, and 12 LTS without forcing "await import()". +JHB: No. I would like an explanation of how to write a package in Node 12 LTS that works in 8, 12 non-LTS, and 12 LTS without forcing "await import()". GB: The only solution we have is the as-is. @@ -127,10 +127,13 @@ MB: It's not reasonable to block unflagging without proposing an alternative sol JHB: Lots of people have blocked things. MB: This is different. - + ACTION: TLA in CJS? + ACTION: Migration guide +ACTION: Respect `type: module` in the cjs resolver + * Revisit dot-main in exports field [#368](https://github.com/nodejs/modules/issues/368) JK: Exports originally had a dot main as a way to drop using main as one field for both. In the very first version there was even a shorthand where if you set exports to a string that would be the main. We dropped that (a) because of the dual package thing, and (b) dot main happened to be somewhat contentious as a way of having a key that was just a dot. But now that we have additional syntax in exports such as the array fallback syntax, we basically come to a choice between two semi-bad options. (1) bring it back - exports can override main completely both for CJS and ESM. or (2) we could support that same array syntax in main but that would mean that if you want to use fallbacks for your main export you would need to drop support for all bundlers before it was introduced. @@ -178,6 +181,3 @@ MB: Agreed. Enables simplicity. * Loader Hooks [#351](https://github.com/nodejs/modules/issues/351) * Package Exports [#341](https://github.com/nodejs/modules/issues/341) * Proposal: Support loading package by own "name" [#306](https://github.com/nodejs/modules/issues/306) - - -