diff --git a/meetings/2021-11-17.md b/meetings/2021-11-17.md new file mode 100644 index 00000000..c0e4264e --- /dev/null +++ b/meetings/2021-11-17.md @@ -0,0 +1,121 @@ +# Node.js Technical Steering Committee (TSC) Meeting 2021-11-17 + +## Links + +* **Recording**: +* **GitHub Issue**: + +## Present + +* Antoine du Hamel @aduh95 (TSC) +* Beth Griggs @BethGriggs (TSC) +* Сковорода Никита Андреевич @ChALkeR (TSC) +* Colin Ihrig @cjihrig (TSC) +* Gireesh Punathil @gireeshpunathil (TSC) +* Matteo Collina @mcollina (TSC) +* Michael Dawson @mhdawson (TSC) +* Richard Lau @richardlau (TSC) +* Robert Nagy @ronag (TSC) +* Michaël Zasso @targos (TSC) +* Tobias Nießen @tniessen (TSC) +* Rich Trott @Trott (TSC) +* Guy Bedford @guybedford (Guest) + +## Agenda + +### Announcements + +* No announcements this week + +### CPC and Board Meeting Updates + +*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. + +* No board meeting update +* No CPC update this week. + +### nodejs/node + +* doc: update conditions, add "deno" and "types" [#40708](https://github.com/nodejs/node/pull/40708) + * conditions in the package.json imports/export + * allow custom resolution + * for those that are not implemented, still value in having them well documented + * examples could be browser or react native condition + * Added a section to the doc called conditions-definitions - + * If not documented, then there could be conflict between implementations using the same + names + * Right now 3 browser, development, production + * Added some guidance as to when conditions can be added to the list + * use case for why should be added to the list + * should be some existing implementations + * etc. + * PR adds 2 new ones, types and deno. Types was added by angular. They do have + others that we have not listed, but did not want to open that can of worms yet. + * Could also be something that we move to the a different repo, place + * Matteo a few concerns, but resolved in the current text + * old text seemed to imply we supported them + * branding/marketing + * Michael - would this make more sense under the OpenJS Foundation + * Guy, a while back considered a package.json spec, but pushback on that. + * Matteo fine with it staying Node.js project + * Michael Z, ok with it staying, but one advantage with being outside, is that it does not need to + be linked to the Node.js documentation. + * Antoine +1 to what Michael Z said + * Michael point that resonated was documenting something that project has not documented. + * Michael Z, also applies to types one, would be good to know that the project wants/intends to define + * Guy, if getting confirmation of project interest make sense to people could be good criteria + * Ronag, kinds of feels out of scope for Node.js project + * which ones are relevant to Node.js + * Matteo in strict terms, maybe just types + * Development/production in webpack + * No objection to landing in core if we get implementor feedback confirmation, + move out later if there is enough momentum to do that later. + +* Rename default branch from "master" to "main" [#33864](https://github.com/nodejs/node/issues/33864) + * No updates this week. + +* Migration of core modules to primordials [#30697](https://github.com/nodejs/node/issues/30697) + * opened to discuss possible options + * Ruben has listed a number of additional options that we should consider + * Ronag, having vote on those 3 is not feasible + * Trott, question of having vote on 3 is different from if those 3 is right. + * too many will not result in positive outcome + * Possible goals + * Tamper Free everywhere + * Tamper Free just for module loading + * Selectively if possible without negative performance + * Not tamper free + * Approaches + * primordials + * move required code to C++ + * Ronag from first question, only viable option is Tamper Free just for X + * Rich probably want to use tamper-resistant + * Gireesh, performance should not be a consideration if people looking for hyper + Performant for areas which are security critical. Rich not sure everybody will agree with that. + * Gireesh, don’t use current performance as baseline. + * Antoine, Bradley’s point was about ESM module system. + * Ronag can make sense in module loading system, performance less important there. + * Michael Z, complication is that module system uses other core modules + * Ronag need list of modules that we want this for, along with deps. + * Gireesh, we should let Ruben pitch in his proposals + * Michael, to me is seems to come back to “where” and “how” as two potential questions. + +### nodejs/TSC + +* add security triaging to core repo GOVERNANCE.md and/or charter? [#1100](https://github.com/nodejs/TSC/issues/1100) + * Rich, putting together a meeting for people who might be willing to be involved in triage + +### nodejs/next-10 + +* Mini- Summit Nov 18 -2021 [#99](https://github.com/nodejs/next-10/issues/99) + * It’s tomorrow. Hope to see people there. + +## Strategic Initiatives + +* No update this week. + +## Upcoming Meetings + +* **Node.js Foundation Calendar**: + +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.