Add napiDependencies 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 napiDependencies field reading from root package.json

new package.json example

{
  "name": "expo-pshenmic-dpp-test",
  "version": "1.0.0",
  "main": "index.ts",
  "scripts": {
    "start": "expo start",
    "android": "expo run:android",
    "ios": "expo run:ios"
  },
  "dependencies": {
    "babel-preset-expo": "^54.0.6",
    "expo": "~54.0.22",
    "expo-build-properties": "~1.0.9",
    "expo-status-bar": "~3.0.8",
    "dash-platform-sdk": "https://github.com/pshenmic/dash-platform-sdk#a6687586eff35faa0a35409be7a97294640cf95f",
    "react": "19.1.0",
    "react-native": "0.81.4",
    "react-native-node-api": "1.0.1"
  },
  "napiDependencies": [
    "pshenmic-dpp"
  ],
  "devDependencies": {
    "@react-native-community/cli": "latest",
    "@babel/core": "^7.25.2",
    "@types/react": "~19.1.0",
    "typescript": "~5.9.2"
  },
  "private": true
}

Here we specify dash-platform-sdk as a dependency, and it contains the dependency pshenmic-dpp, which contains the Node-API module.

[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