Node.js Foundation Modules Team Meeting 2018-06-06 #124
Comments
|
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 #82 (comment), 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?
|
|
@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. |
Time
UTC Wed 06-Jun-2018 19:00 (07:00 PM):
Or in your local time:
Links
Agenda
Extracted from modules-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
nodejs/node
nodejs/modules
Invited
Notes
The agenda comes from issues labelled with
modules-agendaacross 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
The text was updated successfully, but these errors were encountered: