Build

Flags list

Flag	Tipo/Valor padrão	Descrição
`--platform`	`Boolean`/`false`	Adiciona platform triple ao arquivo `.node`. [name].linux-x64-gnu.node por exemplo.
`--release`	`Boolean`/`false`	Bypass para cargo build --release
`--config` ou `-c`	`String`/`package.json`	Caminho da configuração do NAPI, apenas o formato JSON é aceito. O padrão é package.json
`--cargo-name`	`String`/O campo `[package].name` no Cargo.toml sob o comando `cwd`.	`@napi-rs/cli` irá copiar o arquivo `./target/release/lib_[CARGO_NAME].[dll/dylib/so]` para `[NAPI_NAME].[TRIPLE?].node` por padrão. O `[CARGO_NAME]` no caminho de origem é lido do Cargo.toml no `cwd` por padrão. Se você estiver compilando algum outro crate que não seja o cwd atual usando a flag `cargo build -p`, você deve substituir o `CARGO_NAME` com `--cargo-name`.
`--target`	`String`/`undefined`	Bypass para cargo build --target, use esta flag para compilar cruzado. ⚠️ Se nenhum `--target` for especificado, `@napi-rs/cli` invocará `rustup` para determinar o target atual para o qual você está compilando. Certifique-se de ter `rustup` instalado em seu `PATH` se esta flag for omitida.
`--features`	`String`/`undefined`	Bypass para cargo build --features
`--bin`	`String`/`undefined`	Bypass para cargo build --bin
`--const-enum`	`Boolean`/`true`	Gerar `const enum` no arquivo `.d.ts` ou não.
`--dts`	`String`/`index.d.ts`	O nome do arquivo e o caminho do arquivo `.d.ts` gerado, em relação ao comando cwd. Se você não quer que o NAPI-RS gere o arquivo `.d.ts` para você, você pode desabilitar o recurso `type-def` no crate `napi-derive`. ex: `napi-derive = { version = "2", default-features = false }` ⚠️ Se o recurso `type-def` estiver desabilitado, o NAPI-RS também não gerará o arquivo de binding JavaScript para você devido à falta de *informações de tipo*.
`-p`	`String`/`undefined`	Bypass para cargo build -p
`--cargo-flags`	`String`/`''`	All the others flag bypass to cargo build command.
`--js`	`String`/`index.js`	O nome do arquivo e o caminho do arquivo de binding JavaScript, relativos ao diretório de comando `cwd`, Passe false para desativá-lo. Apenas tem efeito se --platform for especificado e o recurso `type-def` em `napi-derive` estiver habilitado.
`--js-package-name`	`String`/`name` campo no package.json sob o comando cwd.	O nome dos pacotes no arquivo de binding js gerado, Apenas afeta se --js for afetado. #Observação ⚠️ Esta flag substituirá o campo `package.name` na configuração do napi Você pode omiti-lo se tiver especificado a configuração `package.name` do napi config
`--cargo-cwd`	`String`/`process.cwd()`	O cwd do `Cargo.toml`. Especifique essa flag se você não deseja passar --cargo-name
`--pipe`	`String`/`undefined`	Encaminhe os arquivos .js/.d.ts gerados para este comando, ex: `prettier -w`
`--zig`	`Boolean`/`false`	`@napi-rs/cli` usará zig (opens in a new tab) como `cc` / `cxx` e `linker` para compilar seu programa.
`--zig-abi-suffix`	`String`/`''`	O sufixo da versão da ABI `zig --target`. Ex: `--target x86_64-unknown-linux-gnu` --zig-abi-suffix=2.17
`--zig-link-only`	`Boolean/false`	`@napi-rs/cli` configurará as variáveis de ambiente `CC` e `CXX` para usar `zig cc`/`zig c++` para compilar cruzadamente as dependências C/C++ nos crates. Mas se você já configurou a cadeia de ferramentas de compilação cruzada C/C++, talvez queira usar apenas `zig` linker de compilação cruzada. Passe esta flag para `@napi-rs/cli` e então não será configurado as variáveis de ambiente `CC` e `CXX` para suas compilações.

Observações para `--js-package-name`

Na seção de aprofundamento, recomendamos que você publique seu pacote sob um escopo npm (opens in a new tab). Mas se você estiver migrando um pacote existente que não está sob um escopo npm (opens in a new tab) ou simplesmente não deseja que seu pacote esteja sob um escopo npm (opens in a new tab) , você pode acionar a deteção de spam do npm (opens in a new tab) ao publicar os pacotes de plataforma nativa. Como snappy-darwin-x64 snappy-darwin-arm64 etc...

Nesse caso, você pode publicar seus pacotes de plataforma sob um escopo npm (opens in a new tab) para evitar a deteção de spam do npm (opens in a new tab). E seus usuários não precisam se preocupar com os pacotes nativos da plataforma em optionalDependencies. Como snappy (opens in a new tab), os usuários só precisam instalá-lo via yarn add snappy. Mas os pacotes nativos da plataforma estão sob o escopo @napi-rs:

{
  "name": "snappy",
  "version": "7.0.0",
  "optionalDependencies": {
    "@napi-rs/snappy-win32-x64-msvc": "7.0.0",
    "@napi-rs/snappy-darwin-x64": "7.0.0",
    "@napi-rs/snappy-linux-x64-gnu": "7.0.0",
    "@napi-rs/snappy-linux-x64-musl": "7.0.0",
    "@napi-rs/snappy-linux-arm64-gnu": "7.0.0",
    "@napi-rs/snappy-win32-ia32-msvc": "7.0.0",
    "@napi-rs/snappy-linux-arm-gnueabihf": "7.0.0",
    "@napi-rs/snappy-darwin-arm64": "7.0.0",
    "@napi-rs/snappy-android-arm64": "7.0.0",
    "@napi-rs/snappy-android-arm-eabi": "7.0.0",
    "@napi-rs/snappy-freebsd-x64": "7.0.0",
    "@napi-rs/snappy-linux-arm64-musl": "7.0.0",
    "@napi-rs/snappy-win32-arm64-msvc": "7.0.0"
  }
}

Para este caso, @napi-rs/cli fornece o --js-package-name para substituir a lógica de carregamento de pacotes gerados. Por exemplo, no snappy, temos um package.json assim:

{
  "name": "snappy",
  "version": "7.0.0",
  "napi": {
    "name": "snappy"
  }
}

Sem a flag --js-package-name, @napi-rs/cli vai gerar a binding JavaScript para carregar pacotes nativos da plataforma para você:

index.js

switch (platform) {
  case 'darwin':
    switch (arch) {
      case 'x64':
        localFileExisted = existsSync(join(__dirname, 'snappy.darwin-x64.node'))
        try {
          if (localFileExisted) {
            nativeBinding = require('./snappy.darwin-x64.node')
          } else {
            nativeBinding = require('snappy-darwin-x64')
          }
        } catch (e) {
          loadError = e
        }
        break
      case 'arm64':
        localFileExisted = existsSync(join(__dirname, 'snappy.darwin-arm64.node'))
        try {
          if (localFileExisted) {
            nativeBinding = require('./snappy.darwin-arm64.node')
          } else {
            nativeBinding = require('snappy-darwin-arm64')
          }
        } catch (e) {
          loadError = e
        }
        break
      default:
        throw new Error(`Unsupported architecture on macOS: ${arch}`)
    }
    break
    ...
}

Isso não é o que queremos. Então, construa com --js-package-name para substituir o package name no arquivo de binding JavaScript gerado: napi build --release --platform --js-package-name @napi-rs/snappy. Em seguida, o arquivo JavaScript gerado se tornará:

index.js

switch (platform) {
  case 'darwin':
    switch (arch) {
      case 'x64':
        localFileExisted = existsSync(join(__dirname, 'snappy.darwin-x64.node'))
        try {
          if (localFileExisted) {
            nativeBinding = require('./snappy.darwin-x64.node')
          } else {
            nativeBinding = require('@napi-rs/snappy-darwin-x64')
          }
        } catch (e) {
          loadError = e
        }
        break
      case 'arm64':
        localFileExisted = existsSync(join(__dirname, 'snappy.darwin-arm64.node'))
        try {
          if (localFileExisted) {
            nativeBinding = require('./snappy.darwin-arm64.node')
          } else {
            nativeBinding = require('@napi-rs/snappy-darwin-arm64')
          }
        } catch (e) {
          loadError = e
        }
        break
      default:
        throw new Error(`Unsupported architecture on macOS: ${arch}`)
    }
    break
    ...
}

Registrando Módulo Artifacts

Build

Flags list

Observações para --js-package-name

Observações para `--js-package-name`