History

• Starting from November 2019, we migrated core modules to primordials
  • Ref: Migration of core modules to primordials node#30697
• On February 2022, TSC took a vote and came to a conclusion to Use primordials in the error path only if there are no significant perf regression.
  • Ref: https://github.com/nodejs/TSC/blob/main/votes/2022-02-21-0.json

Proposal

Due to the performance and several other concerns I propose removing all primordials from the Node.js project. Remember that this is a living document and I'll try to update the following list upon feedback from the community and the TSC.

Pros

• It ensures that Node.js internals are not tampered or acceptable to prototype pollutions.

Cons

• Any prototype pollution in Node.js core is not accepted as a vulnerability in our security/bug bounty program.
  • We use primordials with the purpose of security, but does not include it in our bounty program, which contradicts the notion of security in Node.js
• It creates a friction for optimizing performance, and requires the contributor to benchmark the code with and without the primordials, causing in reality to regress over the performance.
  • One solution for this is to have a performance regression catcher like the benchmarking.nodejs.org but IMHO that's fighting fire with fire.
• V8 doesn't always optimize the primordials efficiently and causes performance regressions, and what Turbofan optimizes are subject to change. This requires constant benchmarking for each V8 release.
  • We have a section that mentions known performance issues but we never follow them. For example, if you search for ArrayPrototypePush in Node.js core, you'll find a lot of examples and usages of primordials with known peformance issues. Reference to the documentation: https://github.com/nodejs/node/blob/HEAD/doc/contributing/primordials.md#primordials-with-known-performance-issues.
  • There are several issues around primordials in Node.js performance repository. Reference: Performance of primordials performance#70
• It creates a higher bar for contribution to Node.js. The primordials.md document is 775 lines on top of our existing documentation, and we don't follow them even though it has explicit examples of what NOT to use - https://github.com/nodejs/node/blob/main/doc/contributing/primordials.md
  • The issue of disallowing certain primordials can be solved with linter rules, but IMHO that's fighting fire with fire.
• There is an existing proposal in TC39 called proposal-symbol-proto for mitigating prototype pollution.
  • Ref: https://github.com/tc39/proposal-symbol-proto

Suggestion

I recommend the removal of primordials from the Node.js project. I strongly believe that it causes more harm then the intended behavior effecting the future of the project causing performance regressions and friction for new contributors.

Appreciate, if you can leave a 👍 or 👎 to this issue.

cc @nodejs/tsc @gireeshpunathil @mcollina @ljharb @BridgeAR