Node.js Modules Team Meeting 2020-02-26

[mhdawson]

Time

UTC Wed 26-Feb-2020 20:00 (08:00 PM):

Timezone	Date/Time
US / Pacific	Wed 26-Feb-2020 12:00 (12:00 PM)
US / Mountain	Wed 26-Feb-2020 13:00 (01:00 PM)
US / Central	Wed 26-Feb-2020 14:00 (02:00 PM)
US / Eastern	Wed 26-Feb-2020 15:00 (03:00 PM)
London	Wed 26-Feb-2020 20:00 (08:00 PM)
Amsterdam	Wed 26-Feb-2020 21:00 (09:00 PM)
Moscow	Wed 26-Feb-2020 23:00 (11:00 PM)
Chennai	Thu 27-Feb-2020 01:30 (01:30 AM)
Hangzhou	Thu 27-Feb-2020 04:00 (04:00 AM)
Tokyo	Thu 27-Feb-2020 05:00 (05:00 AM)
Sydney	Thu 27-Feb-2020 07:00 (07:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Modules%20Team+Meeting+2020-02-26&iso=20200226T20
• or http://www.wolframalpha.com/input/?i=08PM+UTC%2C+Feb+26%2C+2020+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1Evh1h_SAq7VnfXJlt5V8-HX5an6JstVdRE9IkowxU5E/edit

Agenda

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

nodejs/node

• module: disable conditional exports, self resolve warnings #31845
• Add support for extensionless workers and ESM eval #31760
• WIP: Move ESM loaders to worker thread #31229

nodejs/modules

• Chartering the Modules team #412
• Loader Hooks #351
• Patch/Instrument a module #339

Invited

• Modules team: @nodejs/modules

Observers/Guests

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: https://zoom.us/j/656987750
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live

[wesleytodd]

Would folks be willing to talk about nodejs/node#49443? I have not had a chance to revisit and create some performance tests yet, but I would be interested in hearing folks input beyond the general distrust of WHATWG specs and the fact that browsers do not implement it yet (valid concerns, just not very constructive at this point).

[hybrist]

@wesleytodd Afaik we're lacking a clear proposal of what a more realistic flow would look like so I'm not sure there's much to discuss right now. Added a comment on the issue as well with my current thoughts.

[wesleytodd]

I can (and will) respond over there, but I am wondering what you mean by a "more realistic flow"? This could mean two things:

• the implementation details I outlined are not realistic
• getting adoption is not realistic

As for not having anything to talk about in a call, even getting a clear understanding of what next steps would be to see that concerns (ones which actually have possibly constructive answers) are resolved.

[hybrist]

even getting a clear understanding of what next steps would be to see that concerns (ones which actually have possibly constructive answers) are resolved.

I won't stand in the way of having a few minutes to get a more precise list of concerns / outstanding questions. :) But I think your phrasing is unfortunate: I don't think that it's fair to reject all concerns unless there's a possible constructive answer. Because there are concerns (e.g. around the maturity of import maps as a finalized spec) that are perfectly valid imo and have no constructive answer. Unless you count "wait until it's complete".

I don't think going into a discussion about an initial proposal with a very specific implementation ("implement parsing import maps from a JSON file as a built-in feature in node") with a mindset of "this implementation choice definitely is correct" is valuable. And "only concerns that have a constructive answer" somewhat implies that you're mostly interested in hearing things that support your specific proposal.

In the past, this group already discussed how node will "implement import maps". And for now our answer has been: My making it possible to model the node resolution algorithm using (realistic) import maps. Given a lack of tools that actually generate a (set of?) import maps that node could use, this still seems like the most valuable thing we can do to support import maps. Node itself may not use them but modules running in node should be able to use them when running in browsers.

We added exports to allow tools to generate import maps in many scenarios. Afaik nobody has taken this step yet. So it's not like people are running in our doors adopting import maps where node did add support. :)

[wesleytodd]

Because there are concerns (e.g. around the maturity of import maps as a finalized spec)

Sorry, I was specifically talking about the concerns with WHATWG as a standards body and/or if browsers are invested currently in implementing it. The maturity of the spec itself is a valid concern which we should take seriously. But AFAIK noone actually had issue with the content of the spec itself.

I don't think going into a discussion about an initial proposal with a very specific implementation ("implement parsing import maps from a JSON file as a built-in feature in node") with a mindset of "this implementation choice definitely is correct" is valuable

I am sorry if I implied that, because it was not my intent. My hope was that we discuss the pros and cons of this and other approaches. But again, in that thread folks did not bring up those type of concerns mostly. And AFAIK the ones which were brought up were addressed.

We added exports to allow tools to generate import maps in many scenarios. Afaik nobody has taken this step yet.

I intend to, but I am very much not a lone wolf, so before going through that excercize I wanted to get feedback and start this conversation.