|
| 1 | +# Node.js Technical Steering Committee (TSC) Meeting 2021-10-06 |
| 2 | + |
| 3 | +## Links |
| 4 | + |
| 5 | +* **Recording**: <https://youtu.be/CYv575Bps9M> |
| 6 | +* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1092> |
| 7 | + |
| 8 | +## Present |
| 9 | + |
| 10 | +* Antoine du Hamel @aduh95 (TSC) |
| 11 | +* Beth Griggs @BethGriggs (TSC) |
| 12 | +* Ruben Bridgewater @BridgeAR (TSC) |
| 13 | +* Сковорода Никита Андреевич @ChALkeR (TSC) |
| 14 | +* Colin Ihrig @cjihrig (TSC) |
| 15 | +* Danielle Adams @danielleadams (TSC) |
| 16 | +* Gireesh Punathil @gireeshpunathil (TSC) |
| 17 | +* Matteo Collina @mcollina (TSC) |
| 18 | +* Michael Dawson @mhdawson (TSC) |
| 19 | +* Myles Borins @MylesBorins (TSC) |
| 20 | +* Michaël Zasso @targos (TSC) |
| 21 | +* Rich Trott @Trott (TSC) |
| 22 | +* Bradley Farias @bmeck (Guest) |
| 23 | +* Jordan Harband @ljharb (Guest) |
| 24 | + |
| 25 | +## Agenda |
| 26 | + |
| 27 | +### Announcements |
| 28 | + |
| 29 | +* 17.0.0 coming this month, 16.x goes LTS |
| 30 | +* NodeConf on in 2 weeks |
| 31 | +* Security release next week |
| 32 | + |
| 33 | +### CPC and Board Meeting Updates |
| 34 | + |
| 35 | +* No board meeting update this week |
| 36 | +* No update this week, no CPC meeting this week. |
| 37 | + |
| 38 | +*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. |
| 39 | + |
| 40 | +### nodejs/node |
| 41 | + |
| 42 | +* doc: add initial list of technical priorities [#40235](https://github.com/nodejs/node/pull/40235) |
| 43 | + * Michael FYI to TSC, please review, comments. |
| 44 | + |
| 45 | +* Replace OpenSSL 1.1.1 with OpenSSL 3.0.0 [#40106](https://github.com/nodejs/node/issues/40106) |
| 46 | +* deps: update openssl to quictls/openssl 3.0.0+quic (wip) [#38512](https://github.com/nodejs/node/pull/38512) |
| 47 | + * No concerns/objections from those in the meeting today? |
| 48 | + |
| 49 | +* module: unflag import assertions [#39921](https://github.com/nodejs/node/pull/39921) |
| 50 | + * Antoine - going to be discussed in next loaders meeting, if goes well don’t need input |
| 51 | + from TSC. |
| 52 | + |
| 53 | +* Rename default branch from "master" to "main" [#33864](https://github.com/nodejs/node/issues/33864) |
| 54 | + * a few more moved over, some discussion on how we address the core repo. |
| 55 | + |
| 56 | +* Migration of core modules to primordials [#30697](https://github.com/nodejs/node/issues/30697) |
| 57 | +* Bradley |
| 58 | + * Different arguments on why/purpose |
| 59 | + * From my perspective primordials are not the goal, but they are a technique for making parts |
| 60 | + of Node.js more robust in the face of tampering |
| 61 | + * For most environments, the loading mechanism, the part that puts code into executable |
| 62 | + space is protected. Often done by signing/integrity checks. It’s about knowing when you load |
| 63 | + code off disk, people have not tampered with that file |
| 64 | + * Primordials make contribution extremely difficult to node core. |
| 65 | + * Would be easier if we ported parts off of core off our own “dialect” would be good to port in |
| 66 | + way that is not subject to pollution. Before primordials we used safe globals |
| 67 | + * If we defined defensible parts of node core and then restricted it to just that it would help |
| 68 | + enabling contributors. |
| 69 | + * Gireesh, what do you think the impact would be on performance? |
| 70 | + * Personally don’t think that performance needs to be great when it’s enabled |
| 71 | + * Matteo, why is it ok for loading things be slow? |
| 72 | + * Bradley should not slow it down from where it is now |
| 73 | + * Slow part is integrity checks, opt in |
| 74 | + * Primordials, we have seen perf challenges, cannot easily make 2 paths. |
| 75 | + * Ruben, transpiling of code to make opt-in, |
| 76 | + * Bradley, many large projects tried that but were not successful, so don’t think it will work |
| 77 | + * Recommendation |
| 78 | + * Move parts of core out of JavaScript(C/C++, WASM, something else?) mark those as defensible parts |
| 79 | + * CommonJS loader, not filesystem, not path lookup |
| 80 | + * ESM Loader (already pretty good) |
| 81 | + * Policy Mechanism |
| 82 | + * Http or remote code loading. |
| 83 | + * Matteo that would pull in all core |
| 84 | + * Bradley if you run on separate thread then ok |
| 85 | + * Move the rest back to regular JavaScript |
| 86 | + * Should not change bar for contributing for this part as already high, by doing this we could improve for the other areas. |
| 87 | +* Jordan |
| 88 | + * Strange if I can trivially break unrelated code. For example if I delete builtins in Node.js lots of |
| 89 | + things will fail. Feels strange that platform is brittle in this way. Discovered by testing built-ins |
| 90 | + * More concrete topic is mechanism that it makes it self robust. The current approach (because |
| 91 | + no solution language) is not ergonomic and V8 does not optimize. |
| 92 | + * No attachment to current approach, but don’t know of a better one. |
| 93 | + * TC39 bind proposal might help us avoid the performance cliffs that we are seeing |
| 94 | + * The questions that have been discussed in the primordials calls have been |
| 95 | + * stop |
| 96 | + * do at all costs |
| 97 | + * do some carefully |
| 98 | + * just do module loading paths, but hard as it uses other parts of Node.js |
| 99 | + * My proposal would be to |
| 100 | + * continue to harden against this tampering |
| 101 | + * work on specific cases where there is a performance cliff |
| 102 | + * Prioritize robustness and compromise when necessary |
| 103 | + * Matteo |
| 104 | + * One additional impact, JEST for example does work in some cases because of the |
| 105 | + primordials. By removing the functionality it does have an impact |
| 106 | + * GraphQL module does instanceof, using in JEST. |
| 107 | + * Michael Z, problem with JEST is because they run in a vm, that is what causes the problem |
| 108 | + * Bradley, TC39 does have a terms for the things you cannot replace globally. “Undeniables”. |
| 109 | + Trying to state that it is safe to replace globals, it is not true based on TC39 |
| 110 | + * Antoine - new TC39 bind proposal does this change anything for our case (<https://github.com/js-choi/proposal-bind-this-operator>) |
| 111 | + * Bradley, still think it would still be a specific odd dialect of JavaScript. |
| 112 | + |
| 113 | +### nodejs/TSC |
| 114 | + |
| 115 | +* To be or not to be in core [#1041](https://github.com/nodejs/TSC/issues/1041) |
| 116 | + * Rich, last week agreed to try to consolidate into pull request |
| 117 | + * <https://github.com/nodejs/node/pull/40338> |
| 118 | + * Michael one comment is whether it should be limited for any functionality. |
| 119 | + * Matteo agreed should be more general |
| 120 | +## Strategic Initiatives |
| 121 | + |
| 122 | +* Core Promise APIs no update |
| 123 | +* V8 Currency |
| 124 | + * V8 version 9.4 should be updated today, |
| 125 | + * PR to update to 9.5, hope we can get into 17.x, but there are issues with compilation on |
| 126 | + windows, but not sure if it will be in time. |
| 127 | + |
| 128 | +## Upcoming Meetings |
| 129 | + |
| 130 | +* **Node.js Foundation Calendar**: <https://nodejs.org/calendar> |
| 131 | + |
| 132 | +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. |
0 commit comments