Node.js Foundation Modules Team Meeting 2018-08-15

[MylesBorins]

Time

UTC Wed 15-Aug-2018 19:00 (07:00 PM):

Timezone	Date/Time
US / Pacific	Wed 15-Aug-2018 12:00 (12:00 PM)
US / Mountain	Wed 15-Aug-2018 13:00 (01:00 PM)
US / Central	Wed 15-Aug-2018 14:00 (02:00 PM)
US / Eastern	Wed 15-Aug-2018 15:00 (03:00 PM)
London	Wed 15-Aug-2018 20:00 (08:00 PM)
Amsterdam	Wed 15-Aug-2018 21:00 (09:00 PM)
Moscow	Wed 15-Aug-2018 22:00 (10:00 PM)
Chennai	Thu 16-Aug-2018 00:30 (12:30 AM)
Hangzhou	Thu 16-Aug-2018 03:00 (03:00 AM)
Tokyo	Thu 16-Aug-2018 04:00 (04:00 AM)
Sydney	Thu 16-Aug-2018 05:00 (05:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Modules%20Team+Meeting+2018-08-15&iso=20180815T19
• or http://www.wolframalpha.com/input/?i=07PM+UTC%2C+Aug+15%2C+2018+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/11SQ4Ib5jdyusHPJfGG_aJR2lsTAX1oAiiGklL2EHxhw/edit?usp=sharing
• Previous Minutes Google Doc: https://docs.google.com/document/d/11oDyvFSnPp3mkyvr8SwRQTKo4aEu9Z0khIiQKPdT1Yk/edit

Agenda

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

approving PRs (2 minute timebox)

• Nominate @SMotaal as an active member #162

Update on Progress (4 minute timebox)

• Create Terminology.md #158
  • 2 minute timebox
• Developer Survey #85
  • 2 minute timebox

Discussion (50 minute timebox)

• Thinking about deadlines #123
  • 5 minute Timebox
• Managing fork and agreed upon minimal kernel #166
  • 10 minute timebox
• ESM in .js files:
  • ESM in .js files proposals #150
  • Proposals for configuring parse goals of files in --experimental-modules #160
  • 20 minute timebox
• transparent-or-not interop #90
  • 15 minute timebox

Invited

• Modules team: @nodejs/modules

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

[hybrist]

Guess we lost our spot. :D

[Fishrock123]

Ah, zoom. Well, shelve whatever thought that was for next time I guess.

[MylesBorins]

It looks like someone else from the foundation started a meeting. We'll bring transparent interop up at the begining of the next meeting

@kborchers do we have any insight into getting more zoom accounts to avoid something like this happening, it was very disruptive

[giltayar]

At least it allowed to finish @jkrems sentence in the notes! :-)

[SMotaal]

Yeah... I think we were all really immersed into it this time, which is obviously a thing to appreciate

[kborchers]

I will look into additional zoom accounts and will report back.

[giltayar]

All - I had a flaky connection for about 5 minutes while I was taking notes, so there are lots of '???' interspersed in the notes. Feel free to dive in and add what you said during that time.

…

On Wed, Aug 15, 2018 at 11:53 PM Kris Borchers ***@***.***> wrote: I will look into additional zoom accounts and will report back. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#167 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYnRAMWaVDq-cR0-WXox-JSKZxk5miAks5uRIomgaJpZM4V9QIO> .

[GeoffreyBooth]

So I think we got cut off before getting a chance to discuss next steps, though it seems like @MylesBorins has the next steps in hand for starting development on the new minimal implementation.

Since the current implementation is remaining in core, I’d like to work to improve it, even as we work in parallel on new implementation(s). To that end, I’d like to try to make a PR for #160. I think there’s a case to be made for merging that into core, along with a PR to implement a CLI flag so that ESM can be used with --eval.

Members of the group who hadn’t read that thread before this week’s meeting, please take a look and add your feedback. Please remember that it’s strictly within the context of the current --experimental-modules implementation; it says nothing about whatever changes other implementations may make. I also don’t think we need to figure out our plan for loaders just to build this PR; we can implement this along the lines of nodejs/node#18392, and things can change as the loaders implementation matures.

I’ve never written a PR for Node core before, and I don’t know C++, so I need some help with this. Is there anyone in the group interested in making ESM in .js happen who would like to help?

[MylesBorins]

I'm -1 on moving that to core right now. This makes sense as something that can land in the fork. We definitely do not have consensus on per package scoped loaders.

…

On Fri, Aug 17, 2018, 11:24 AM Geoffrey Booth ***@***.***> wrote: So I think we got cut off before getting a chance to discuss next steps, though it seems like @MylesBorins <https://github.com/MylesBorins> has the next steps in hand for starting development on the new minimal implementation. Since the current implementation is remaining in core, I’d like to work to improve it, even as we work in parallel on new implementation(s). To that end, I’d like to try to make a PR for #160 <#160>. I think there’s a case to be made for merging that into core, along with a PR to implement a CLI flag so that ESM can be used with --eval. Members of the group who hadn’t read that thread before today’s meeting, please take a look and add your feedback. Please remember that it’s strictly within the context of the current --experimental-modules implementation; it says nothing about whatever changes other implementations may make. I also don’t think we need to figure out our plan for loaders just to build this PR; we can implement this along the lines of nodejs/node#18392 <nodejs/node#18392>, and things can change as the loaders implementation matures. I’ve never written a PR for Node core before, and I don’t know C++, so I need some help with this. Is there anyone in the group interested in making ESM in .js happen who would like to help? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#167 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV26ss3A0369j0ayd-OCGWgIIFyoCks5uRuAagaJpZM4V9QIO> .

[michael-ciniawsky]

@GeoffreyBooth Why making a PR against core if there will be a fork ? (generally speaking)

I’ve never written a PR for Node core before, and I don’t know C++, so I need some help with this. Is there anyone in the group interested in making ESM in .js happen who would like to help?

I am, but sry to be quite blunt here, definitely not with your current proposal and absolutely not anything involving MIME (which, sry again, simply doesn't make any sense at all) :). How about pkg.module for ESM analog to how pkg.main works for CJS ? Simple and straightforward

When will the fork be up and running? Will non nodejs/modules members be able to open PR there?

[devsnek]

@GeoffreyBooth i'm happy to mentor any prs you want to make

[ljharb]

@michael-ciniawsky a module field simply won’t work because there’s more than just ESM and CJS. There’s also wasm, and infinite potential future parsing goals. Altho I’m not a fan of mimes, the current suggestion of a mapping from extension to something is probably the best and only viable option imo.

[zenparsing]

This is a sidebar, but my intuition would be that the loader would use the extension when presented with a pkg.module (using ESM for ".js").

[michael-ciniawsky]

I don't understand why this wouldn't work but I'm also not claiming it 💯 does. Where does pkg.module fall short here and limits (potential) use cases ? In a nutshell all I suggest is

package.json

{
 module: 'path/to/src/file.ext'
}

package.json

{
 module: 'path/to/src/file.js' // if .js will be supported for ESM (different issue)
 module: 'path/to/src/file.mjs'
 module: 'path/to/src/file.wasm'
 module: 'path/to/src/file.html' // if ever supported (different issue)
 module: 'path/to/src/file.{ts, tsx, jsx, coffee, ...}' // plus loaders if ever supported (different issue)
 ...
}

to get started with

[michael-ciniawsky]

If following the module graph doesn't work because of other decisions made in another area, then maybe a per package boundary is needed instead e.g

package.json

{
 module: true
}