spec - load-native.test.ts

Referenced by4

Labels4

Idea	Status	Tags	Summary	Katz
rust_binary_distribution	in-progress		One platform-specific npm package per [native_targets] tuple: `@reqlan/analytical-<platform>-<arch>` ( napi suffixes: `linux-x64-gnu`, `linux-arm64-gnu`, `darwin-x64`, `darwin-arm64`, `win32-x64-msvc`, `win32-arm64-msvc` ). Each package declares `os` and `cpu`, contains the matching core engine `.node`, and uses the `@reqlan/analytical` package. json version as the single source of truth. ["../../scripts/prepare-native-packages.mjs"] writes that version. Changesets ignores `@reqlan/analytical-` in ["../../.changeset/config.json"]. Git `@reqlan/analytical` does not list platform packages as `optionalDependencies`; this workspace links them through `packageExtensions` in ["../../pnpm-workspace.yaml"]. The published tarball lists pinned optionalDependencies ( `--publish-versions` ) ( [version_management] ). CLI and MCP install the host-matching binary from those published optionalDependencies. The published tarball runs ["./native_host_binary.rq".published_host_native_install] so a host miss prints a warning. Published on the existing `analytical/v` channel ( [npm_distribution] / [release_tagging] ); not a separate tag channel. The napi build runs when this channel moved: a direct `analytical/v` tag, or `analytical_tag` from [deployment_flow]. The first npm tag ( `npm_ref` ) can be `language/v` in the same release, so that ref is not the native-build gate. Website download listing and GitHub-release postinstall are later follow-ups ( out of scope here ). Engine port: ["../core_analysis/rust_port.rq".analytical_rust_port] / ["../core_analysis/rust_port.rq".native_bridge]. Per-target VSIX packaging uses the same package layout under ["../../packages/analytical-native/"], filled by Azure from this git commit ( [vsix_export], [vsix_native_not_from_npm] ). npm tarballs of those packages are for CLI / MCP only. `collect-napi-binary.mjs` copies `reqlan-lsp` only with `--with-lsp`. The npm workflow does not pass that flag. Azure does, because the VSIX ships `bin/reqlan-lsp` ( [vsix_export] ). Implementation: ["../../packages/analytical-native/"], ["../../scripts/prepare-native-packages.mjs"], ["../../scripts/require-natives-published.mjs"], ["../../packages/analytical/scripts/check-host-native.mjs"], ["../../.changeset/config.json"], ["../../.github/workflows/deploy-npm.yml"] build-native job, ["../../azure-pipelines.yml"] build_native job.	0.380
native_host_binary	done		Select the native core-engine binary from the extension host. The host is the Node process that runs the extension. Read `process.platform` and `process.arch` from that process. Do not use the platform of the VS Code UI client. Examples: - UI on Windows and host on Linux SSH: use a linux tuple. - UI on Windows and host on WSL: use a linux tuple. - UI and host on macOS: use a darwin tuple. Map the platform and the arch to one tuple in ["./distribution.rq".native_targets]. Load only the binary that matches that tuple. Do not load a binary for a different tuple. If the platform and the arch are not in ["./distribution.rq".native_targets], fail. If the binary is missing, fail. Do not use sql. js. Keep the loader map the same as ["../../scripts/native-targets.mjs"]. Local development: [native_host_binary_development]. Production distribution: [native_host_binary_distributed]. Implementation: ["../../packages/analytical/src/native/load-native.ts"].	0.144
native_host_binary_development	done		Use this procedure on a developer machine ( F5 and `pnpm run build` ). Identify the host from `process.platform` and `process.arch` of the build process. The build process and the extension host must be the same machine. Copy the matching `.node` file to `packages/extension/native/reqlan_napi.node`. Write `packages/extension/native/target.json` with the host tuple. If the binary is not present, build it with `cargo build -p reqlan-napi -p reqlan-lsp --release`. At run time, search in this order: 1. The `native/` folder of the extension, if `target.json` records the host tuple. 2. The resolved `main` of the host npm package ( `createRequire` from `@reqlan/analytical/package.json` ). 3. The host file in `packages/analytical-native/<napiSuffix>/` ( workspace package directory, same layout as a published package ). 4. The host npm package name. 5. `crates/target/<rustTarget>/release` and `crates/target/release`. 6. The debug folders with the same names. Do not search packages for other platforms. If `target.json` records a different tuple, do not load `native/reqlan_napi.node`. Windows cargo emits `reqlan_napi.dll`; the loader uses `process.dlopen` for `.dll` and `.node` ( Node `require` only loads `.node` ). Windows UI with a WSL extension host uses the linux tuple ( [native_host_binary] ). Windows UI with a Windows extension host cannot load a `.node` staged from WSL; restage on Windows or open the folder in a WSL remote window. Before tests, the workspace host package must contain the `.node` so loaders behave like production ( [native_host_binary_distributed] ). `scripts/ensure-host-native.mjs` uses an existing matrix binary, or cargo locally. Azure compiles the ["./distribution.rq".native_targets] matrix from git and stages those artifacts; it does not fetch binaries from npm. Detail: [development_build.extension_host_native_stage]. Implementation: ["../../scripts/stage-host-native.mjs"], ["../../scripts/ensure-host-native.mjs"], ["../../packages/extension/src/analytical_submodule/index.ts"].	0.078
native_host_binary_distributed	in-progress		Use this procedure for a published VSIX and for published npm packages. VS Code extension: The registry installs the VSIX that has `targetPlatform` equal to the extension host. Each VSIX contains one `.node` file for one ["./distribution.rq".native_targets] tuple. The file name is `native/reqlan_napi.node`. The VSIX also contains `native/target.json`. At run time, read `process.platform` and `process.arch` on the extension host. If `target.json` records a different tuple, do not load `native/reqlan_napi.node`. Do not put binaries for other platforms in that VSIX. The Azure pipeline compiles each platform binary from this git commit ( `build_native` + `collect-napi-binary.mjs` + `prepare-native-packages.mjs --binary-dir` ). Package versions in git are canonical. The pipeline does not wait for npm. Related: ["./distribution.rq".vsix_export], ["./distribution.rq".extension_distribution], ["./distribution.rq".vsix_native_not_from_npm]. CLI and MCP: npm installs the host package from `optionalDependencies` on the published `@reqlan/analytical` tarball. Git does not list those entries. ["../../scripts/prepare-native-packages.mjs"] `--publish-versions` writes them at npm publish. The loader resolves that package from `@reqlan/analytical/package.json` ( `createRequire` ), which is where the optional dependency is attached after `npm install`. Published installs also run [published_host_native_install]. Related: ["./distribution.rq".rust_binary_distribution], [rust_port.native_bridge]. Implementation: ["../../scripts/package-extension-targets.mjs"], ["../../scripts/prepare-native-packages.mjs"], ["../../packages/analytical/src/native/load-native.ts"], ["../../packages/analytical/scripts/check-host-native.mjs"], ["../../azure-pipelines.yml"].	0.129

Reference labels

native_host_binary, native_host_binary_development, native_host_binary_distributed, rust_binary_distribution