Package specific configuration (for apps and libraries)

No se nombran archivos de implementación ni pruebas. Empieza por resolver el esquema de configuración, el comportamiento de búsqueda, las reglas de escaneo de dependencias y el manejo de rutas específico de cada plataforma propuestos aquí; se considera terminado cuando el proyecto tenga un diseño de configuración acordado y documentado, así como un comportamiento claro para cada opción.

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
  }
}