Function setup 

pub fn setup()

Configure the build of a napi-rs addon crate.

Call it from the addon’s build.rs. Besides the per-platform link arguments, it hands the crate a first-party cfg(napi_wasi_threads), set exactly when the crate is compiled for wasm32-wasip1-threads:

// build.rs
fn main() {
  napi_build::setup();
}

// src/lib.rs
#[cfg(napi_wasi_threads)]
const SHARED_MEMORY: bool = true;
#[cfg(not(napi_wasi_threads))]
const SHARED_MEMORY: bool = false;

rustc has no built-in cfg that tells the two WASI targets apart: it prints an identical cfg set for wasm32-wasip1 and wasm32-wasip1-threads (same target_env = "p1"), and the wasm atomics target feature is unstable, so the stable channel never puts target_feature = "atomics" in the cfg set of either one (rust-lang/rust#77839). Only the exact cargo TARGET answers the question, and only a build script can read it.

A build-script cfg is crate-local: it reaches the crate whose build.rs called this function and nothing else. Every other crate in the graph that needs the distinction needs its own build script. Absence must therefore be the conservative branch — a plain cargo build compiles the not(napi_wasi_threads) side, and that side has to stay correct.