module: expose getPackageScopeConfig & add findNearestPackageJSON

[JakobJingleheimer]

This draft is not ready for review. Opening it in its current state for visibility.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[anonrig]

Can we be explicit? Depending on the package.json this can overwrite existing values in this object

[JakobJingleheimer]

No, we can't be explicit because we don't know what the keys are—that's the point of this feature ;) also, we don't need to worry about overwriting because this is a rest spread.

[JakobJingleheimer]

I'm planning to adjust GetPackageJSON to optionally include all fields from the package.json. I think for unrecognised fields, I need to generically handle (parse) each kind of valid json value. Does that functionality already exist in c++, or do I need detect each type and handle the parsing specifically?

GetPackageJSON currently has a loop with a bunch of if (key = …), else if (key = …), else if (key = …). If I need to handle each kind of value, I'm thinking to extract those to some kind of hash-map:

• PJSONParsers['exports']
• PJSONParsers['imports']
• PJSONParsers['name']
• PJSONParsers['script']
• PJSONParsers['type']
• …
• PJSONParsers['default'] ← handles unrecognised fields (which can have any valid json value, and calls various "nonspecific*" methods on PJSONParsers)
• PJSONParsers['nonspecificString']
• …
• PJSONParsers['nonspecificMap'] ← will call other "nonspecific*" methods

Side-note: I haven't worked in c++ in ~20 years, so I can't remember if there is potentially a performance implication here. I'm thinking extracting those avoids re-constructed on each loop (but that may be offset by the cost of function call(s)).

[JakobJingleheimer]

Splitting this into atomic PRs:

• module: add findNearestPackageJSON utility #55173