Modules: 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

[jkrems]

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 [e-mail]
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
https://github.com/nodejs/modules/issues/167#issuecomment-413332616, 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 https://github.com/nodejs/node/pull/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 [e-mail]
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
https://github.com/nodejs/modules/pull/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 https://github.com/nodejs/node/pull/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
https://github.com/nodejs/modules/issues/167#issuecomment-413900576, 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
}

[zenparsing]

@michael-ciniawsky

If following the module graph doesn't work because of other decisions in another area

I'm not sure what this means, can you clarify?

[MylesBorins]

Hey all. Can we move the conversation not related to this meeting to
another thread.

😇

On Fri, Aug 17, 2018, 2:22 PM Kevin Smith [e-mail] wrote:

@michael-ciniawsky https://github.com/michael-ciniawsky

If following the module graph doesn't work because of other decisions in
another area

I'm not sure what this means, can you clarify?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nodejs/modules/issues/167#issuecomment-413949855, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAecV7XG1bDb1y8PCzefw0wpn9KWqiRAks5uRwnngaJpZM4V9QIO
.

[michael-ciniawsky]

Sure if there was a proposals section in the repo I would just write one about all this and make a PR to discuss it there instead, while refraining from randomly commenting every time this pops up somewhere 😇 :D

@zenparsing Happy to clearify it and/or write a doc to work on it (focused). In an nutshell once one knows the entry of a package (e.g via pkg.module) follow the import/import() and require() statements etc or use the file extension (e.g in case of transparent interop)... There a different possibilities (unrelated to packages), but all that fuss is not really needed to be expressed via package.json by users imho. One can simply infer it 'down the graph'

Edit: 'Infer' especially refers to specifier type (e.g import/import()/require) and shape (e.g 'bare' for packages import('bare')), but the discussion about package handling e.g via pkg.module is already within/for a specific type && shape imho. So one step ahead :)

[sendilkumarn]

@GeoffreyBooth 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 interested and I can help a bit 🙂