Package specific configuration (for apps and libraries)

実装ファイルやテストは指定されていません。まず、ここで提案されている設定スキーマ、検索動作、依存関係スキャンのルール、プラットフォーム固有のパス処理を整理してください。プロジェクトで合意済みかつ文書化された設定設計が確立され、各オプションの動作が明確になれば完了です。

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 and we would like to continue to support packages providing Node-API modules without requiring package-specific configuration.

How to configure

We could rely on cosmiconfig (which is also used by the React Native Community CLI):

By default, Cosmiconfig will check the current directory for the following:

• a package.json property
• a JSON or YAML, extensionless "rc file"
• an "rc file" with the extensions .json, .yaml, .yml, .js, .ts, .mjs, or .cjs
• any of the above two inside a .config subdirectory
• a .config.js, .config.ts, .config.mjs, or .config.cjs file

We could load this config starting from the "app" and then look for it in all direct dependencies of the app package and all transitive dependencies explicitly enumerated - see below.

What to configure

Possible configuration options which could optimise the experience:

Library name mapping to paths

We could allow library authors to provide explicit paths for the Node-API prebuilds bundled with their package:

{
  // Alternative names for this property could be "addons" or "modules"? 🤔
  "prebuilds": [
    // Provide a path for a prebuild
    "./build/Release/somthing.node",
    // Which would be an alias for an object with the same path
    { "path": "./build/Release/somthing.node" },
    // Allow overriding the name (default would be "my-lib--addon") used for the library files when linked into the app
    { "name": "addon", "path": "./build/Release/addon.node" },
    // Allow specifying platform-specific paths
    {
      "name": "addon",
      "path": {
        "android": "./build/Release/addon.android.node",
        "ios": "./build/Debug/addon.apple.node"
      },
    },
  ]
}

Control scanning

We could group options related to scanning for Node-API modules, either under a "scanning" (or simply "scan") key.

We could enable scanning of specific transitive dependencies (see #367 for use-case)

{
  "scanning": {
    "dependencies": ["name-of-lib-with-node-api-module"]
  }
}

We could provide lists of glob patterns to include and exclude when scanning for modules

{
  "scanning": {
    "include": ["./build"],
    "exclude": ["./node_modules"],
  }
}

Or disable scanning all together:

{
  "scanning": {
    "disabled": true
  }
}