UTC Wed 06-Jun-2018 19:00 (07:00 PM):
| Timezone | Date/Time |
|---------------|-----------------------|
| US / Pacific | Wed 06-Jun-2018 12:00 (12:00 PM) |
| US / Mountain | Wed 06-Jun-2018 13:00 (01:00 PM) |
| US / Central | Wed 06-Jun-2018 14:00 (02:00 PM) |
| US / Eastern | Wed 06-Jun-2018 15:00 (03:00 PM) |
| London | Wed 06-Jun-2018 20:00 (08:00 PM) |
| Amsterdam | Wed 06-Jun-2018 21:00 (09:00 PM) |
| Moscow | Wed 06-Jun-2018 22:00 (10:00 PM) |
| Chennai | Thu 07-Jun-2018 00:30 (12:30 AM) |
| Hangzhou | Thu 07-Jun-2018 03:00 (03:00 AM) |
| Tokyo | Thu 07-Jun-2018 04:00 (04:00 AM) |
| Sydney | Thu 07-Jun-2018 05:00 (05:00 AM) |
Or in your local time:
Extracted from modules-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
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.
@jdalton will once again chair as I can't commit to attending while on the road. I did not yet apply timeboxes to the agenda items, please feel free to do so.
Is there someone from the project who has access to zoom who can commit to helping to kick off / stream the meeting? (@mhdawson ?)
Unfortunately I will not be able to join.
@devsnek would you be willing to present "loader: warn when the user imports a module with a thenable namespace" for the modules team so we can either vote on it or open a follow up issue members can vote on?
@benjamingr unfortunately i won't be able to make it to this one due to my finals
Good luck with your finals!
In the interest of making progress, could we maybe prioritize finishing reviewing the last few use cases and making features out of them? And discuss what comes next after that? I suggested a possible way forward in https://github.com/nodejs/modules/issues/82#issuecomment-392356408, I’d love to hear what the group thinks of that idea.
I also asked those who are concerned with browser equivalence and spec compliance to submit use cases or features covering those topics. Assuming that these features are supposed to lead toward development, I think it’s important to get everyone’s priorities represented.
@GeoffreyBooth i'm not sure what those use cases would look like. are these good?
"Tom expects that when node.js is doing something from the language spec it does it correctly"
"Tom expects that when node.js is doing something with modules that browsers also do they do it the same way"
@devsnek Those would work, though could we also get more specific? What are particular parts of the language spec that you’re concerned that the implementation might break?
Ideally we would also have user-centered use cases that explain why these are important. I think there probably _are_ some real use cases for these, like “Tom writes a library that imports modules. He expects his library to function the same way when it’s run in Node and run in browsers.” Or “Tom writes a library that exports itself as an ES module. He expects his library to function the same way when it’s imported in a Node app as when it’s imported in a browser script.” Et cetera. It’s useful to understand why users should care about spec compliance and browser equivalence, so that the importance is clear.
@GeoffreyBooth as long as we're implementing esm, which is itself defined in the language spec, staying as general as possible would seem to be the best option. If we have things we wiggle on it isn't esm anymore.
as for browser stuff i'm not quite sure how to phrase it. i wanna say something that encapsulates the apis, behaviours, etc of modules, but nothing else (e.g. node doesn't currently have fetch)
@GeoffreyBooth I've filled out a few more use cases, but I do want to say that I don't know how useful they are at this point. We have identified a ton of features and we have a fairly broad set of requirements. At this point, while we can continue to come up with more use cases to drive features, I don't believe we need to start stack ranking based on how many use cases exist.
IMHO, which I am very open to changing, is that we need to come up with clear proposals that combine features and offer a story for ecosystem transition and multimode modules
Just saw the request for me to start the stream. Doing that now.
Do we have a meeting link yet?
Link to join https://zoom.us/j/656987750
Wow... completely missed thread this altogether — distracted prototyping an experimental playground for you guessed it modules which can be used to model and compare discussed ideas & features 😊
Hey all, it seems like notes were not taken in the google doc during this meeting. Were they taken somewhere else?
I believe @DanielRosenwasser took notes.
Most helpful comment
Link to join https://zoom.us/j/656987750