Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node.js Technical Steering Committee (TSC) Meeting 2023-09-27 #1442

Closed
mhdawson opened this issue Sep 25, 2023 · 7 comments · Fixed by #1449
Closed

Node.js Technical Steering Committee (TSC) Meeting 2023-09-27 #1442

mhdawson opened this issue Sep 25, 2023 · 7 comments · Fixed by #1449
Assignees

Comments

@mhdawson
Copy link
Member

Time

UTC Wed 27-Sep-2023 13:00 (01:00 PM):

Timezone Date/Time
US / Pacific Wed 27-Sep-2023 06:00 (06:00 AM)
US / Mountain Wed 27-Sep-2023 07:00 (07:00 AM)
US / Central Wed 27-Sep-2023 08:00 (08:00 AM)
US / Eastern Wed 27-Sep-2023 09:00 (09:00 AM)
EU / Western Wed 27-Sep-2023 14:00 (02:00 PM)
EU / Central Wed 27-Sep-2023 15:00 (03:00 PM)
EU / Eastern Wed 27-Sep-2023 16:00 (04:00 PM)
Moscow Wed 27-Sep-2023 16:00 (04:00 PM)
Chennai Wed 27-Sep-2023 18:30 (06:30 PM)
Hangzhou Wed 27-Sep-2023 21:00 (09:00 PM)
Tokyo Wed 27-Sep-2023 22:00 (10:00 PM)
Sydney Wed 27-Sep-2023 23:00 (11:00 PM)

Or in your local time:

Links

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/admin

  • Collaborator Changes - More Privacy #834
  • Have a mascot #828
  • Create nodejs/socket repository for Node.js implementation of Cloudflare's Socket API #826

Invited

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-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.

Joining the meeting

Zoom link: https://zoom.us/j/611357642
Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.


Invitees

Please use the following emoji reactions in this post to indicate your
availability.

  • 👍 - Attending
  • 👎 - Not attending
  • 😕 - Not sure yet
@mhdawson mhdawson self-assigned this Sep 25, 2023
@LiviaMedeiros
Copy link

IIRC nodejs/node#49531/#49629 should be on the agenda.

@GeoffreyBooth
Copy link
Member

IIRC nodejs/node#49531/#49629 should be on the agenda.

What is the question or issue that you would like the TSC to resolve?

We discussed those PRs last week and I described my suggested rollout from nodejs/node#49531 (comment) and no one objected. I opened nodejs/node#49869 as the first step of that plan.

@LiviaMedeiros
Copy link

What is the question or issue that you would like the TSC to resolve?

  1. Semverity - there were mixed opinions but not much arguments towards any. I'd prefer this to be resolved by TSC to avoid unnecessary overcaution nor overlooking valid reason to be conservative.

  2. Lifting the current objection. Most of reasons to do so covered in the discussion, but tl;dr landing it as part of esm: --experimental-default-type flag to flip module defaults node#49869 would give a few critical issues:

  • It won't work properly in module scope by default; e.g. own "./bin/" files in packages that are not ready to flip mode, or any scripts that use minimalistic pjson while not being a part of package.
  • It will be unusable in any published projects, because flag stops working under /node_modules/ directory.
  • It will gatekeep support for any non-ESM extensionless files (only wasm atm) under ESM flag.
  • After being extracted or after the actual default flip, it will introduce unnecessary breaking change to scripts that can work only in this mode.
  • It will indirectly block any further additions to --type flag for the same reason why we can't overload --input-type: users who just need extensionless scripts will get a bunch of unwanted side effects.

Benefits of landing it as part of flag:

There was the blocking concern of "users will get frustrated if we have extless ESM in scope but not outside of scope" but now that nodejs/node#49869 exists it's not a problem: extless support from nodejs/node#49629 will perfectly work with --type flag, just like if stray files were inside of module scope.
Having extless loose ESM without any flag at all right now is not possible, because extless loose files are interpreted as CJS. On a longer distance, if plan from nodejs/node#49432 about flipping the unflagged default succeeds, it will work out of the box as well, just like if there was a global module scope.

I hope I made it clear.

@benjamingr
Copy link
Member

@LiviaMedeiros any chance you can attend the TSC meeting if we discuss this so we have more context and can ask questions?

@LiviaMedeiros
Copy link

Sure. What's needed from my side to attend?

@GeoffreyBooth
Copy link
Member

GeoffreyBooth commented Sep 26, 2023

For reference, here’s the objection: nodejs/node#49531 (review).

My PR nodejs/node#49869 satisfies all the requests in the objection, and includes the support for extensionless ESM and Wasm files in module scopes from the blocked PRs, albeit behind an experimental flag. So I think what’s really being asked of the TSC here is that that behavior in the blocked PRs can be released unflagged, even before nodejs/node#49531 lands, is that correct?

I don’t think that shipping support for extensionless ESM and Wasm files in module scopes needs to be semver-major. I had commented on that thread how someone might argue that it’s semver-major, but not that I held that view. If others want to take a look, that would be good to get consensus on. But I’m not blocking on that point.

And since nodejs/node#49869 exists now, I’ll lift my block as soon as that lands and has been in the wild for a bit without issue. I mentioned as much in the PR description for nodejs/node#49869. I don’t think we need to wait for the entire 21 release lifetime; it’s not a semver-major change, so a few minor releases (so a month or two) should probably be sufficient, assuming we don’t get a ton of bug reports.

@GeoffreyBooth
Copy link
Member

Sure. What’s needed from my side to attend?

@LiviaMedeiros Please either send an email to [email protected] or contact individual TSC members on the OpenJS Slack: https://openjs-foundation.slack.com and someone can share instructions on how to join the meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants