Skip to content

Latest commit

 

History

History
132 lines (110 loc) · 6.15 KB

2021-10-06.md

File metadata and controls

132 lines (110 loc) · 6.15 KB
Raw

Node.js Technical Steering Committee (TSC) Meeting 2021-10-06

Links

Present

  • Antoine du Hamel @aduh95 (TSC)
  • Beth Griggs @BethGriggs (TSC)
  • Ruben Bridgewater @BridgeAR (TSC)
  • Сковорода Никита Андреевич @ChALkeR (TSC)
  • Colin Ihrig @cjihrig (TSC)
  • Danielle Adams @danielleadams (TSC)
  • Gireesh Punathil @gireeshpunathil (TSC)
  • Matteo Collina @mcollina (TSC)
  • Michael Dawson @mhdawson (TSC)
  • Myles Borins @MylesBorins (TSC)
  • Michaël Zasso @targos (TSC)
  • Rich Trott @Trott (TSC)
  • Bradley Farias @bmeck (Guest)
  • Jordan Harband @ljharb (Guest)

Agenda

Announcements

  • 17.0.0 coming this month, 16.x goes LTS
  • NodeConf on in 2 weeks
  • Security release next week

CPC and Board Meeting Updates

  • No board meeting update this week
  • No update this week, no CPC meeting this week.

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

nodejs/node

  • doc: add initial list of technical priorities #40235

    • Michael FYI to TSC, please review, comments.

  • Replace OpenSSL 1.1.1 with OpenSSL 3.0.0 #40106

  • deps: update openssl to quictls/openssl 3.0.0+quic (wip) #38512

    • No concerns/objections from those in the meeting today?

  • module: unflag import assertions #39921

    • Antoine - going to be discussed in next loaders meeting, if goes well don’t need input from TSC.

  • Rename default branch from "master" to "main" #33864

    • a few more moved over, some discussion on how we address the core repo.

  • Migration of core modules to primordials #30697

  • Bradley

    • Different arguments on why/purpose
    • From my perspective primordials are not the goal, but they are a technique for making parts of Node.js more robust in the face of tampering
    • For most environments, the loading mechanism, the part that puts code into executable space is protected. Often done by signing/integrity checks. It’s about knowing when you load code off disk, people have not tampered with that file
    • Primordials make contribution extremely difficult to node core.
    • Would be easier if we ported parts off of core off our own “dialect” would be good to port in way that is not subject to pollution. Before primordials we used safe globals
    • If we defined defensible parts of node core and then restricted it to just that it would help enabling contributors.
    • Gireesh, what do you think the impact would be on performance?
    • Personally don’t think that performance needs to be great when it’s enabled
    • Matteo, why is it ok for loading things be slow?
    • Bradley should not slow it down from where it is now
    • Slow part is integrity checks, opt in
    • Primordials, we have seen perf challenges, cannot easily make 2 paths.
    • Ruben, transpiling of code to make opt-in,
    • Bradley, many large projects tried that but were not successful, so don’t think it will work
    • Recommendation
    • Move parts of core out of JavaScript(C/C++, WASM, something else?) mark those as defensible parts
      • CommonJS loader, not filesystem, not path lookup
      • ESM Loader (already pretty good)
      • Policy Mechanism
      • Http or remote code loading.
      • Matteo that would pull in all core
      • Bradley if you run on separate thread then ok
    • Move the rest back to regular JavaScript
    • Should not change bar for contributing for this part as already high, by doing this we could improve for the other areas.

  • Jordan

    • Strange if I can trivially break unrelated code. For example if I delete builtins in Node.js lots of things will fail. Feels strange that platform is brittle in this way. Discovered by testing built-ins
    • More concrete topic is mechanism that it makes it self robust. The current approach (because no solution language) is not ergonomic and V8 does not optimize.
    • No attachment to current approach, but don’t know of a better one.
    • TC39 bind proposal might help us avoid the performance cliffs that we are seeing
    • The questions that have been discussed in the primordials calls have been
      • stop
      • do at all costs
      • do some carefully
      • just do module loading paths, but hard as it uses other parts of Node.js
    • My proposal would be to
      • continue to harden against this tampering
      • work on specific cases where there is a performance cliff
      • Prioritize robustness and compromise when necessary
    • Matteo
      • One additional impact, JEST for example does work in some cases because of the primordials. By removing the functionality it does have an impact
      • GraphQL module does instanceof, using in JEST.
      • Michael Z, problem with JEST is because they run in a vm, that is what causes the problem
      • Bradley, TC39 does have a terms for the things you cannot replace globally. “Undeniables”. Trying to state that it is safe to replace globals, it is not true based on TC39
    • Antoine - new TC39 bind proposal does this change anything for our case (https://github.com/js-choi/proposal-bind-this-operator)
    • Bradley, still think it would still be a specific odd dialect of JavaScript.

nodejs/TSC

  • To be or not to be in core #1041
    • Rich, last week agreed to try to consolidate into into pull request
    • Michael one comment is whether it should be limited for any functionality.
    • Matteo agreed should be more general

Strategic Initiatives

  • Core Promise APIs no update
  • V8 Currency
    • V8 version 9.4 should be updated today,
    • PR to update to 9.5, hope we can get into 17.x, but there are issues with compilation on windows, but not sure if it will be in time.

Upcoming Meetings

Click +GoogleCalendar at the bottom right to add to your own Google calendar.