diff --git a/meetings/2024-07-17.md b/meetings/2024-07-17.md new file mode 100644 index 00000000..5bd38f13 --- /dev/null +++ b/meetings/2024-07-17.md @@ -0,0 +1,147 @@ +# Node.js Technical Steering Committee (TSC) Meeting 2024-07-17 + +## Links + +* **Recording**: +* **GitHub Issue**: + +## Present + +* Antoine du Hamel @aduh95 (voting member) +* Benjamin Gruenbaum @benjamingr (voting member) +* Ruben Bridgewater @BridgeAR (voting member) +* Geoffrey Booth @GeoffreyBooth (voting member) +* Marco Ippolito @marco-ippolito (voting member) +* Matteo Collina @mcollina (voting member) +* Michael Dawson @mhdawson (voting member) +* Rafael Gonzaga @RafaelGSS (voting member) +* Richard Lau @richardlau (voting member) +* Robert Nagy @ronag (voting member) +* Paolo Insogna @ShogunPanda (voting member) +* Joe Sepi @ (Guest - Node.js CPC rep) + +## Agenda + +### Announcements + +* Rafael about to promote 22.5.0 ! + +### Reminders + +* Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/recognizing-contributors.md#bi-monthly-contributor-spotlight) + +* Actively looking for location for collaborator summit for the days after NodeConf.eu. If your + company could provide a space we love to hear from you. + +### CPC and Board Meeting Updates + +*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. + +* CPC update + * working on code of conduct team selection processes + +* Board meeting update + * No updates from the board this week + +### nodejs/node + +* module: unflag detect-module [#53619](https://github.com/nodejs/node/pull/53619) + * Geoffrey, discussing with Antoine to split out the work. Main question is if we are ok with + landing change to flag. Flag continues to exist, but default becomes on. Would stay as + experimental, we could backport to 22, and would let it back there for a while. + * Michael, if I remember correctly, this one we thought was not breaking, but has a higher + chance that it might cause unforeseen issues. So better to have in 22 before goes LTS. + * Geoffrey/Matteo correct. + * No objections from TSC members in the meeting. + +* inspector: add initial support for network inspection [#53593](https://github.com/nodejs/node/pull/53593) + * Chrome helped us resolve the issue and Chengzhong is helping it along :) + * Chengzhong: reaching out to Danil to draft a design doc + * Benjamin, positive reaction from Chrome dev tools team and progress is being made. + * agenda tag already removed + +* module: add --experimental-strip-types [53725](https://github.com/nodejs/node/pull/53725) + * Benjamin, strategic decisions, lots of stake holders. Good to make a few decisions to help + conversation along. + * Benjamin, ok to land and iterate, but we allow as much breakage etc. + * Matteo, 2 takes. + * First one is that we should try to have meeting with the Typescript team. Should wait until + we get their feedback. Seems like the asked for some time. Ok with landing and removing + later + * Marco + * Currently blocked as swc having trouble with some architectures so still some time before + it would land anyway. + * Feedback from TypeScript team is that there are some concerns but they can be solved. Created package to wrap swc which + would go under the Node.js organization. + * This would allow us to move versions forward more easily. + * With that said waiting is good, how long and should be block based on that? + * Paolo + * Even for experimental features we overthink things. We should release something and + experiment and gather feedback from others + * Geoffrey + * main concern, I tried it out and there needs to be way better error messages. Had + discussed landing but holding it back until docs are updated to avoid swarm of confused + users. Can help write those. Not necessarily a need to rush. + * In terms of the TypeScript team, none of them are collaborators but they obviously want to + block, do we want to progress with it in that state? + * Matteo + * I agree with Geoffrey. We should talk to TypeScript team, ask for a timeline, have a meeting + with them. They are a key part of the ecosystem. We should not likely ship something they + are not ok with unless we are really sure it is what our users need. + * Michael + * If its more like a PoC, then possibly a compile time guard makes sense + * Paolo + * ok if we wait for feedback from the TypeScript team if we timebox it. + * Robert + * If we don’t compile it by default, then no point because people won’t try it out. + * We could just wait until the PR is ready versus garding + * Geoffrey, would like to give them timeline that would let us hit 23. Also why not both? + previous approach was to error and then have output that would tell people + to run X to install. Strip types could be limited and then hooks + could be used for full integration. + * Do people agree that we should update docs? That would mean waiting a few weeks + * Antoine + * If it stays as a PR it’s hard for people to contribute to it. If it’s not in main, the bar is high for + test. We may only get 10 people using it with compile flag but that is more than if it waits as + a PR + * In terms of docs, early adopters don’t necessarily need good docs + * Paolo, seems reasonable to give TypeScript team at most one month. In terms of docs, we + don’t want to set in stone, and its a lot of work to update docs. + * Matteo, would give TypeScript team until the end of august + * Benjamin, lets try and get Daniel on the TSC meeting next week and voice their concerns + * Marco, have gotten some positive feedback from people on tc39 + * Proposal is to: + * externalize into npm module + * include the npm module in Node.js just like npm + * already created the PR to do that. + * will create WASM from source code + * PR will look similar, but will include source code and wrap swc + * Benjamin + * Can we agree on landing + * Antoine, only the compile time option is on the table because of the architectures side of + Things. Marco believe latest version from swc will be addressed + * Geoffrey, land but hold back from release, but increases the chances of backports + * Richard, likely not a Node.js 22.x release in next few weeks anyway. + * Michael + * one approach, land in main with compile time option, backport that to 22.x, then remove + the compile time option in main. That keeps most code consistent for backporting while + not enabling in 22.x in shipping versions. If its not ready for 23 we could then re-add + the compile time guard (or not if it is ready) + +### nodejs/TSC + +* New Strategic Initiative on Primordials [#1439](https://github.com/nodejs/TSC/issues/1439) + * Nothing to discuss until we hear back from Antoine and Ruben on their recommendations + +### nodejs/next-10 + +* Next 10 - Funding Deep Dive [#273](https://github.com/nodejs/next-10/issues/273) + * should have been removed from the agenda, nothing to discuss. + +## Strategic Initiatives + +## Upcoming Meetings + +* **Node.js Project Calendar**: + +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.