module: empty object fix in InternalModuleReadJSON for #30245

[guybedford]

This fixes the bug posted in #30245, where having a package.json with no "type" field would not apply the CommonJS default.

The issue turned out to be that InternalModuleReadJSON applies a string filter to avoid parsing unnecessary package.json files, but the case of the filter failing and a file being not found were indistinguishable. (and that is why in that issue report, having a "repository" field with a "type" was enough to get it to work again!)

The implemented fix returns "{}" for when the filter finds no known package.json properties, to indicate it exists but has no properties we are interested in to avoid treating it the same as a not found package.json file. This way the default can still apply.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[guybedford]

Thinking about this package.json read function a little more - it could be beneficial to write a custom package.json parser that applies the filtering during parsing itself. Since we scan the string now multiple times for each of the possible properties anyway it should actually be faster than the existing approach.

A C++ JSON parser that builds up JavaScript objects just for the "main" / "exports" / "type" fields we care about should be ideal for perf since the number of properties is always small.

[devsnek]

Can you handle this on the JS side instead? wasting time parsing objects we know are already empty is not ideal.

[guybedford]

@devsnek the saving of not having to parse the JSON source still applies - since we are just parsing JSON.parse("{}") for package.json files which are known not to have properties we need. This really is not a performance concern.

It would be slower performance to fix on the JS side because we would need to do a stat + a load of JSON instead of just trying to load the file.

[devsnek]

@guybedford isn't it just checking if the function returns undefined?

[guybedford]

The bug is that undefined is being returned both for a package.json file that does not exist and a package.json file that does exist but doesn't pass the filter. So we can't distinguish between not found files and existing files with no fields we care about.

[devsnek]

That makes sense. If we don't have benchmarks for this already it might be worth adding them. In the past a lot of work went into optimizing package.json loading for cjs, and I'd imagine its slowed down a lot since then with all the work to esm.

[MylesBorins]

LGTM

[guybedford]

Would be great to get another approval here to land this bug fix soon.

[guybedford]

//cc @jkrems

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/26459/

edit:

re running windows CI
https://ci.nodejs.org/job/node-test-commit-windows-fanned/31070/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/26464/

[Trott]

Landed in 1eee0b8