Node.js Foundation Modules Team Meeting 2018-08-15 #167
Comments
|
Guess we lost our spot. :D |
|
Ah, zoom. Well, shelve whatever thought that was for next time I guess. |
|
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 |
|
At least it allowed to finish @jkrems sentence in the notes! :-) |
|
Yeah... I think we were all really immersed into it this time, which is obviously a thing to appreciate |
|
I will look into additional zoom accounts and will report back. |
|
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>
.
|
|
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 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 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 |
|
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>
.
|
|
@GeoffreyBooth Why making a PR against core if there will be a fork ? (generally speaking)
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 When will the fork be up and running? Will non |
|
@GeoffreyBooth i'm happy to mentor any prs you want to make |
|
@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. |
|
This is a sidebar, but my intuition would be that the loader would use the extension when presented with a |
|
I don't understand why this wouldn't work but I'm also not claiming it 💯 does. Where does
{
module: 'path/to/src/file.ext'
}
{
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 |
|
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
{
module: true
} |
I'm not sure what this means, can you clarify? |
|
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>
.
|
|
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 Edit: 'Infer' especially refers to specifier type (e.g |
I am interested and I can help a bit 🙂 |
Time
UTC Wed 15-Aug-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.
approving PRs (2 minute timebox)
Update on Progress (4 minute timebox)
Discussion (50 minute timebox)
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: