Node.js Foundation Modules Team Meeting 2018-08-15 #167

Activity

1. hybrist commented on Aug 15, 2018

   

   hybrist

   on Aug 15, 2018

   Contributor

   More actions

   Guess we lost our spot. :D

   😄React with 😄3Reacted by Jordan Harband, Hassan Sani and Benjamin Gruenbaum
2. Fishrock123 commented on Aug 15, 2018

   

   Fishrock123

   on Aug 15, 2018

   Contributor

   More actions

   Ah, zoom. Well, shelve whatever thought that was for next time I guess.
3. MylesBorins commented on Aug 15, 2018

   

   MylesBorins

   on Aug 15, 2018

   ContributorAuthor

   More actions

   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

   👍React with 👍1Reacted by Jordan Harband
4. giltayar commented on Aug 15, 2018

   

   giltayar

   on Aug 15, 2018

   More actions

   At least it allowed to finish @jkrems sentence in the notes! :-)
5. SMotaal commented on Aug 15, 2018

   

   SMotaal

   on Aug 15, 2018

   More actions

   Yeah... I think we were all really immersed into it this time, which is obviously a thing to appreciate
6. kborchers commented on Aug 15, 2018

   

   kborchers

   on Aug 15, 2018

   More actions

   I will look into additional zoom accounts and will report back.

   ❤️React with ❤️2Reacted by Jordan Harband and Benjamin Gruenbaum
7. giltayar commented on Aug 16, 2018

   

   giltayar

   on Aug 16, 2018 via email

   More actions

   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 ***@***.***> 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 <#167 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYnRAMWaVDq-cR0-WXox-JSKZxk5miAks5uRIomgaJpZM4V9QIO> .
8. GeoffreyBooth commented on Aug 17, 2018

   

   GeoffreyBooth

   on Aug 17, 2018

   Last edited by GeoffreyBooth

   Member

   More actions

   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 nodejs/node#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?
9. MylesBorins commented on Aug 17, 2018

   

   MylesBorins

   on Aug 17, 2018 via email

   ContributorAuthor

   More actions

   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 ***@***.***> 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 <#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 <nodejs/node#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 <#167 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV26ss3A0369j0ayd-OCGWgIIFyoCks5uRuAagaJpZM4V9QIO> .
10. michael-ciniawsky commented on Aug 17, 2018

    

    michael-ciniawsky

    on Aug 17, 2018

    Last edited by michael-ciniawsky

    More actions

    @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?

    👍React with 👍1Reacted by Kevin Smith
11. devsnek commented on Aug 17, 2018

    

    devsnek

    on Aug 17, 2018

    Member

    More actions

    @GeoffreyBooth i'm happy to mentor any prs you want to make
12. ljharb commented on Aug 17, 2018

    

    ljharb

    on Aug 17, 2018

    SponsorMember

    More actions

    @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.
13. zenparsing commented on Aug 17, 2018

    

    zenparsing

    on Aug 17, 2018

    More actions

    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").
14. michael-ciniawsky commented on Aug 17, 2018

    

    michael-ciniawsky

    on Aug 17, 2018

    Last edited by michael-ciniawsky

    More actions

    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
15. michael-ciniawsky commented on Aug 17, 2018

    

    michael-ciniawsky

    on Aug 17, 2018

    Last edited by michael-ciniawsky

    More actions

    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
    }
16. zenparsing commented on Aug 17, 2018

    

    zenparsing

    on Aug 17, 2018

    More actions

    @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?
17. MylesBorins commented on Aug 17, 2018

    

    MylesBorins

    on Aug 17, 2018 via email

    ContributorAuthor

    More actions

    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 ***@***.***> 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 <#167 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV7XG1bDb1y8PCzefw0wpn9KWqiRAks5uRwnngaJpZM4V9QIO> .

    👍React with 👍1Reacted by Jordan Harband
18. michael-ciniawsky commented on Aug 17, 2018

    

    michael-ciniawsky

    on Aug 17, 2018

    Last edited by michael-ciniawsky

    More actions

    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 :)
19. sendilkumarn commented on Aug 17, 2018

    

    sendilkumarn

    on Aug 17, 2018

    Contributor

    More actions

    @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 🙂
20. MylesBorins

    closed this as completedon Sep 12, 2018