Skip to content
This repository has been archived by the owner on Sep 2, 2023. It is now read-only.

Node.js Foundation Modules Team Meeting 2019-01-30 #258

Closed
MylesBorins opened this issue Jan 29, 2019 · 10 comments
Closed

Node.js Foundation Modules Team Meeting 2019-01-30 #258

MylesBorins opened this issue Jan 29, 2019 · 10 comments

Comments

@MylesBorins
Copy link
Contributor

MylesBorins commented Jan 29, 2019

Time

UTC Wed 30-Jan-2019 20:00 (08:00 PM):

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

Or in your local time:

Links

Agenda

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

Announcements

  • --eval, STDIN, and extensionless files #251

Discussion

  • Slack channel #249
    • 5 minute timebox
  • Dynamic Modules Development in Node.js #24894
    • 15 minute timebox
  • Minimum to release? #253
    • 15 minute timebox
  • WIP [Do not merge] - Irp type dynamic modules #29
    • 15 minute timebox
    • Refs:
      • Mode: esm proposal #247
  • Import file specifier proposal implementation #256
    • 5 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

@MylesBorins
Copy link
Contributor Author

Lots of items @guybedford and @GeoffreyBooth is this an accurate representation of proposals to discuss and enough time?

@GeoffreyBooth
Copy link
Member

GeoffreyBooth commented Jan 29, 2019

Let’s bump “minimum to release” to next meeting? After tomorrow’s meeting I’ll create a new issue to survey members on that so we have real data on that before we discuss it, and not a thread that got hijacked. I want to wait until after the meeting though to see if we hopefully merge in the import file specifier proposal implementation, as that would provide a new baseline for what remaining features people would want before releasing.

Perhaps we could reorder from least to most controversial? So I think that would be:

  • Slack channel
  • Import file specifier proposal implementation
  • --eval, STDIN, and extensionless files (this is just a call for interested parties to join a working group, nothing more yet; but assumes import file specifier proposal implementation is approved)
  • Dynamic modules

I’m hoping that the earlier items should hopefully take less time than their timebox, saving more time for dynamic modules.

@guybedford
Copy link
Contributor

Added the agenda label to the Dynamic Modules issue here - #252 (comment). It would be great to include at least 10 minutes for this if possible.

@guybedford
Copy link
Contributor

Ahh, I see this is already covered by #24894, 10 mins would be preferable I think though over 5.

@weswigham
Copy link
Contributor

Ah. It's been ended.

Anyways, I was going to ask this when we were done, but will we be able to get a set of the tc39's concerns with dynamic modules and who objected to what, so we can specifically iterate to alleviate those concerns and run the changes by those individuals before bringing the proposal forward again? Because this whole "do something that seems ok in our group and then bring it to the other group once a month where different people show up with different concerns" is a really long winded process, and since we're looking to accelerate the time we're doing things in, short circuiting that through direct collaboration is probably a way we can work through it in a reasonable timeframe.

@ljharb
Copy link
Member

ljharb commented Jan 30, 2019

My understanding of the bulk of the concern is the same as @jdalton's; that export * from 'cjs' in a cycle wouldn't work.

@weswigham
Copy link
Contributor

weswigham commented Jan 30, 2019

Brad and Myles mentioned some other concerns, too, though (something about editing SourceTextModuleRecord at all among some others), and the people with those concerns will also need to be worked with. I don't think zeroing in on one issue is going to help too much with going forward (although I'm personally sure that's fixable if you're OK with larger spec adjustments) if the same people speak up again with the same concerns the next time it's brought forward.

@MylesBorins
Copy link
Contributor Author

I'll follow up with folks who had concerns to get a list together

@arcanis
Copy link

arcanis commented Feb 1, 2019

I was looking at the minutes regarding the "Minimum to release?" thread (and particularly with regard to loaders, as PnP would be a good guinea pig), but it's not clear to me whether there's been a resolution1. Would someone have more details?

1 pun intended

@MylesBorins
Copy link
Contributor Author

MylesBorins commented Feb 1, 2019 via email

MylesBorins added a commit to MylesBorins/modules that referenced this issue Feb 13, 2019
MylesBorins added a commit that referenced this issue Feb 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants