src: move package_json_reader cache to c++

[anonrig]

Co-authored by @lemire

Local Benchmark

My local benchmarks says that running vite --version is 5% faster

❯ hyperfine 'node ../sveltejs-realworld/node_modules/vite/dist/node/cli.js --version' 'out/Release/node ../sveltejs-realworld/node_modules/vite/dist/node/cli.js --version' -w 10
Benchmark 1: node ../sveltejs-realworld/node_modules/vite/dist/node/cli.js --version
Time (mean ± σ): 101.4 ms ± 0.6 ms [User: 96.6 ms, System: 10.8 ms]
Range (min … max): 100.3 ms … 102.5 ms 28 runs
Benchmark 2: out/Release/node ../sveltejs-realworld/node_modules/vite/dist/node/cli.js --version
Time (mean ± σ): 96.3 ms ± 0.5 ms [User: 90.9 ms, System: 10.1 ms]
Range (min … max): 95.6 ms … 98.1 ms 30 runs
Summary
out/Release/node ../sveltejs-realworld/node_modules/vite/dist/node/cli.js --version ran
1.05 ± 0.01 times faster than node ../sveltejs-realworld/node_modules/vite/dist/node/cli.js --version

TODOs

• Move modules functionality to node_modules.cc
  • internalModuleReadJSON
• Move caching of package_json_reader to C++
  • Make node_modules.cc snapshottable
• Update run_main.js to just avoid constructing the whole object for the entry point.
  • We could even call containsModuleSyntax from C++
• Move getPackageScopeConfig from package_config.js to C++ side, and cache it on node_modules.cc
• Replace all packageJSONReader calls that looks for specific attribute to have equivalent C++ functions
• Investigate if imports & exports JSONParse needs to be cached on JS

Caveats

• ERR_INVALID_PACKAGE_CONFIG does not include JSON.Parse() error message anymore. This mainly because we're using simdjson to avoid JS allocation while parsing for performance reasons.
• exports/imports without string, array or object value will now throw ERR_INVALID_PACKAGE_CONFIG instead of returning an invalid value.

Benchmarks

• Startup bench: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1468

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/loaders
• @nodejs/startup

[RafaelGSS]

@anonrig See #50954 (review).

[RafaelGSS]

Adding dont-land labels again.

[anonrig]

The mentioned issue is fixed in #50965

[RafaelGSS]

Applying semver-minorPRs that contain new features and should be released in the next minor version. because we're adding a new dependency to Node.js (0dd53da)

[marco-ippolito]

@anonrig I would like to land this on v20 but its not landing cleanly, can you backport?

[BridgeAR]

@anonrig this seems to cause a major performance regression. I did not look deeper into this but it's causing test code to run about 10x slower when running the following example code: DataDog/dd-trace-js#5360

[anonrig]

@anonrig this seems to cause a major performance regression. I did not look deeper into this but it's causing test code to run about 10x slower when running the following example code: DataDog/dd-trace-js#5360

@BridgeAR Happy to take a look. Can you share a reproduction that doesn't require any external knowledge, and open a new issue and tag me?

[BridgeAR]

I can't look into it closer at the moment. Since about 80% of all time is taken in Node.js when running the example, I guess it should be fine to check the source code to cause the problem.
It is actually just a redirected issue report, due to originally being reported in aws/aws-cdk#33576.

I'll open a issue about it though.