Add reactNativeNodeApi field support for package.json

[owl352]

Issue

At the moment, we cannot import Node-API dependencies unless they are explicitly declared in package.json #366. However, there are valid use cases where a user installs a package that depends on an Node-API module. For example, it could be an SDK that includes the Node-API module.

Right now, there is only 2 workaround: manually adding that package to dependencies or manually linking. This is far from ideal, as it complicates the migration flow between versions of the dependency that relies on this package.
I see only two potential solutions at the moment: scan the entire node_modules directory, or get a “hint” from somewhere about which modules require auto-linking. I consider the first option to be bad, as it requires a lot of resources.

The goal of this PR is to introduce a separate configuration field in package.json that allows specifying package names for auto-linking, without interacting with the package manager in any way.

Things done

• Updated package-lock.json
• Added reactNativeNodeApi field reading from package.json for project and depencies for project

new package.json example

{
  "name": "expo-pshenmic-dpp-test",
  "version": "1.0.0",
  "main": "index.ts",
  "scripts": {
    "start": "expo start",
  },
  "dependencies": {
    "moduleA": "^54.0.6",
  },
  "reactNativeNodeApi": {
    "scan": {
      "dependencies": ["moduleA"]
    }
  },
  "devDependencies": {},
  "private": true
}

The module maintainers can also set the configuration within the module's package.json file. In this case, the configuration section need not be duplicated in the project's package.json.

[kraenhansen]

Overall - I agree this is a problem worth solving 👍 and it seems related to #54.

As a first, we're consciously using "Node-API" / nodeApi instead of "N-API" / napi as this is the name the Node.js project choose going forward and the name used in this proposal is not aligned with that.

[kraenhansen]

We've actively worked towards putting as few restrictions on the packages bringing Node-API modules as possible, to make it more likely to migrate / re-use existing packages intended for Node.js.

I do however see value in (optional) package-specific configuration intended for our tooling with linking efficiently - wrote down a few thoughts that I'd love your input on #368

[kraenhansen]

I'd probably use zod here (already a dependency of the host package), to get runtime errors if the value in the package doesn't match what we expect.

[owl352]

Done ✅

[kraenhansen]

I would have probably assumed this would be added in the findNodeApiModulePathsByDependency implementation 🤔 Perhaps now is a good time to add a couple of tests to make sure we're on the same page in regards to the semantics of the implementation.

One thing I'm wondering is how deep this implementation goes. We want to ensure we support transitive dependencies of arbitrary depth and we probably also want to ensure we break on cycles.

[owl352]

@kraenhansen Okay, I'll add the tests a little later. At the moment, there are actually only two layers: we read the root package.json, as well as the package.json dependencies from the the root package.json