Node.js Loaders Team Meeting 2021-09-15 about loaders HOT 20 CLOSED

We need to find a new time. Friday mornings in general rarely work for me anymore.

Who can make this Wednesday, Sept 15, at 2 pm PT / 5 pm ET / 9 pm UTC / 11 pm CEDT? 👍 or 👎

And can this time work in general for you, every two weeks thereafter? 🚀 for yes, 😕 for no

from loaders.

@arcanis and others, how about this Tuesday Sept 21 at 10 am PT / 7 pm CET?

from loaders.

I think I’ll hold a meeting today at 2 pm PT / 5 pm ET / 9 pm UTC / 11 pm CEDT and whoever can attend is welcome. At the very least @JakobJingleheimer and I need to discuss next steps for chaining, so maybe that’s all that’ll happen. And we can schedule a separate meeting to discuss the utility functions stuff.

from loaders.

Can I attend and #28 be added to the agenda?

Yeah, thanks for bringing this up — needed to copy that label from the core repo to this one.

I have updated the meeting agenda to include you. Any other developers of Yarn's loader are welcome too!

Hope I can make this one myself. We'll see what happens, but your spot is reserved @arcanis. 👍

from loaders.

Can I attend and #28 be added to the agenda? I didn't realize the issue needed to be up before the one for a meeting I could attend was created.

from loaders.

I can't make this time this Friday (work conflict). There was some discussion last week with moving it to 11pm CEST, which I can do.

from loaders.

Who can make this Wednesday, Sept 15, at 2 pm PT / 5 pm ET / 9 pm UTC / 11 pm CEDT?

I can make that time, but think we should ensure that the chosen time properly accommodates @arcanis + entourage seeing as how our invitees already made plans that work with our scheduled time. I have no preference other than making sure that rescheduling has no effect on Yarn representation at our next meeting, so hopefully we can get confirmation before we update OP's meeting time.

from loaders.

I'm traveling this week, and attending outside of work hours (~7am-6pm UTC) will be difficult 😕

from loaders.

I could possibly do a one-off during work hours, but not on a regular basis.

6pm CEST is 9am PT (Geoffrey's time zone).

from loaders.

@GeoffreyBooth, the whole point of having an experimental API is to allow the opportunity to collect feedback in order to iterate.

Having a 2-person-meeting to forge ahead without consulting the rest of the team/group who likely have input on the matter is simply unfair to the rest of us who have spent time and energy thinking about this very problem space. The last time we discussed chaining, we did not seem to have any sort of consensus on what we though the behavior would be like.

from loaders.

@DerekNonGeneric you indicated above that you can attend, and I heard from Jacob and Bradley that they can also both attend, so that’s four people right there. @arcanis’s topics are unrelated to chaining, so we can discuss them at the next meeting where they can attend. I think that’s better than skipping this week entirely.

from loaders.

@arcanis's topics are, indeed, related to chaining, right? Realistically, yarn projects using any loader other than yarn's are going to need to chain with yarn's loader. And yarn's loader requires exposing essentially virtual extensions to the filesystem: yarn's loader exposes files from a zip, other loaders may be interested in reading adjacent files from the same "virtual" directories.

from loaders.

@cspotcode generally we haven't coupled file virtualization with import instrumentation APIs under loaders and they are quite different. For example, it is conceivable that you may want to import a .coffee file which has an virtual file with "number = -42 if opposite" but has an import source text of ("if (opposite) number = -42", "module"). We could spend some time to see if this WG wants to expand scope to such things but the actual composition model for chaining instrumentation of imports seems like it can keep moving forward. I think talk of virtual files/assets is interesting though and look forward to a discussion. I certainly don't think our current work conflicts with them instrumenting getSource etc. allows for arbitrary ways of getting source text.

from loaders.

For future reference, changing the time on a whim without asking is something that we cannot repeat.

These kinds of technical discussions require preparation and I for one did not anticipate a re-scheduling to exclude our invitees to discuss who-knows-what anymore. You all can have your ad-hoc, but hijacking this issue is completely inappropriate. This team/group should operate using Design Reviews in the future and I think we should charter as WG. The part about having “less obligations” may seem appealing, but it probably means that our implementation suffers because of it.

Unstructured discussions about abstract concepts doesn't seem to be very effective to me.

from loaders.

@DerekNonGeneric sorry to have missed you today.

The change has been discussed for multiple weeks in multiple fora.

We need to move the “default” meeting time, because it no longer works for Geoffrey and me. Along with Bradley, we're the regular attendees and contributors, so the meetings need to occur when we can attend. The Wednesday 2 pm PT / 5 pm ET / 9 pm UTC time does that.

We could not accommodate @arcanis's schedule this week, but we plan to do; We're hoping to find a time for the next meeting that works for him too.

I'm sure you can understand the challenges of spanning 9 hours of time-zones. For instance, to respond to you in a considerate time, it is 1am for me.

Today we were not making any sort of decision; I requested insight from Bradley and Geoffrey to help inform the design proposals on chaining and to incorporate feedback we have already received from Andrew and Gil.

from loaders.

@arcanis, @cspotcode, @jonaskello What’s your availability next week, and generally?

I’m working on getting access to be able to adjust the meetings. I’m thinking that we can have an ad hoc meeting next week whenever those involved in #26 are available, and then on the following week we can have our regular meeting as usual (such as at the Wed 9 pm UTC time unless there’s a better time).

from loaders.

from loaders.

Next week I only have a few meetings planned so I could probably join. I'm in the CEST time zone (Sweden). I'm currently not well-read in the area of esm loaders so I'm not sure how much I can contribute to the meeting at this point. However I've started on a PR for ts-node in this area and hopefully I'll have some time this week-end to work more on it so I get a better understanding. I'm also maintaining the tsconfig-paths package which somehow needs to add esm support at some point in time.

from loaders.

9pm UTC is 11pm here; I can do it once in a while, but not on a regular basis. 7am-6pm UTC would be ideal in general.

from loaders.

#31

from loaders.