Node.js Foundation Modules Team Meeting 2018-03-14

[MylesBorins]

Time

UTC Wed 14-Mar-2018 19:00 (07:00 PM):

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

Or in your local time:

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

Links

• Minutes Google Doc: https://docs.google.com/document/d/1fwQ_XkYyJO3p5fE2o9H9i7iWii0LB4OyQxepBlaa6-Y/edit?usp=sharing
• Previous Minutes Google Doc: https://docs.google.com/document/d/1ZA_0tK8ZKoo1Lh2kLl-DIckVnYb7rOV-ASjrsjEW3mI/edit?usp=sharing

Agenda

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

nodejs/modules

Approving PRs ~ 1 minute per item

• doc: add meeting notes for 2018-02-28 #38

For awareness ~ 3 minutes per item

• doc: add MANIFESTO.md #45
• Use Cases Meeting #41
• Online Module Summit #9

Discussion

• Upstream changes to ESM in nodejs/node #42
  • 10 minute timebox
• Use Cases for ESM in Node.js
  • 30 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:
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

[hybrist]

Should we identify a single focus topic / deep dive for this meeting? E.g. getting a good, exhaustive list of use cases we can agree on? Or are we punting on that until April 3rd (or whenever the module summit will be)? It felt like the last meeting got dragged down by the back-and-forth between "answer minor question X" and "we need a general agreement on what we're trying to build here".

[mcollina]

I'm traveling and I probably won't be able to join. I'm ok with whatever decision the team is going to make. Feel free to not count me towards quorum.

The agenda seems too big for one single meeting, should we prioritize a bit?

[jasnell]

I will also be traveling and unable to make the call this week.

[MylesBorins]

The agenda was automated, we can definitely scope it a bit better. TBH using this meeting to focus on user stories / use cases seems like a really solid use of time.

…

On Mon, Mar 12, 2018, 1:35 PM James M Snell ***@***.***> wrote: I will also be traveling and unable to make the call this week. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#47 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV1OxEVqmC3flqcflJ0i7aqLLK5jkks5tdrHOgaJpZM4SnBrv> .

[inidaname]

I may not be able to attend due to a recent attack, I have limited access to PC and Internet. On Mon, Mar 12, 2018 at 6:56 PM, Myles Borins <notifications@github.com> wrote:

…

The agenda was automated, we can definitely scope it a bit better. TBH using this meeting to focus on user stories / use cases seems like a really solid use of time. On Mon, Mar 12, 2018, 1:35 PM James M Snell ***@***.***> wrote: > I will also be traveling and unable to make the call this week. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#47 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ AAecV1OxEVqmC3flqcflJ0i7aqLLK5jkks5tdrHOgaJpZM4SnBrv> > . > — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#47 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE2tHpfE5Fbc_eR243Obx3oEMsX3n0Ccks5tdra6gaJpZM4SnBrv> .

[benjamingr]

Maybe weird request?

I'd prefer it if we started with technical discussion of the nodejs/node technical issues and I ask that people who would like to participate in that discussion enter the actual issues (I try to ping @nodejs/modules on issues when I see them).

Namely,

• I'd love to hear an update about wasm from @linclark in "loader: allow importing wasm modules"
• I'd love us to vote about the _ issue in "esm: provide named exports for all builtin libraries"

[weswigham]

By "the underscore issue" do you mean filtering _ prefixed members from the exposed exports?

[guybedford]

We can remove the mode: "esm" flag item from the agenda, as we already discussed this briefly last week.

[benjamingr]

@weswigham yes

@guybedford how do we proceed with the esm flag item? Don't we need to make a decision about it?

[guybedford]

@benjamingr I'm ok with putting this on the back-burner while we focus on other technical decisions and use cases.

[jdalton]

@benjamingr

I'd love us to vote about the _ issue in "esm: provide named exports for all builtin libraries"

The PR isn't blocked on filtering of _ at the moment. That was worked through a bit ago.

[benjamingr]

@jdalton thanks for the update, reading it: I don't really understand why it's stalled. How can core move forward with named exports for ESM? What needs to be decided before the PR lands?

[jdalton]

@benjamingr

I don't really understand why it's stalled.

It's stuck on a console.log stack count nit at the moment.

What needs to be decided before the PR lands?

Minor things are left, for example now that live bindings of named exports works should setters still be filtered. That said, with the push to remove getter/setters from builtin module exports started before live bindings were thought possible and with things still being experimental, it may not be a super concern esp. for initial support.

[benjamingr]

@jdalton thanks, is this something you think we need to discuss in the meeting, spin off into an issue here or discuss in the main nodejs/node repo? I really want to see named exports for native modules land :)

[jdalton]

@benjamingr

thanks, is this something you think we need to discuss in the meeting, spin off into an issue here or discuss in the main nodejs/node repo?

I think it just needs someone to pop-in and fix the console.log stack issue or better yet find the root cause of the console.log reference issue and fix that.

I really want to see named exports land :)

Same.