Reproduction
I am seeing this on Windows 11 with the Native SDK pinned to @native-sdk/cli@0.10.1.
From the repository root, run the Native CLI directly:
native check apps/native-ui
native test apps/native-ui
If the CLI is not installed globally, the equivalent package-pinned invocation is:
bun x @native-sdk/cli@0.10.1 check apps/native-ui
bun x @native-sdk/cli@0.10.1 test apps/native-ui
The repository convenience scripts are only an optional mapping of those commands:
"ui:check": "bun run scripts/native-sdk-cli.ts check apps/native-ui",
"ui:test": "bun run scripts/native-sdk-cli.ts test apps/native-ui"
The wrapper delegates to the same Native SDK CLI and adds repository-specific Windows environment setup; it is not required for the reproduction above.
That means native test apps/native-ui invokes the Native SDK CLI test command for the app. It first generates and compiles the model contract, then proceeds to the Windows native build. It is not failing in the application TypeScript tests or in the markup check.
The Native CLI 0.10.1 also supports native build [dir]; this report does not require native build because the failing test path is reproduced by native test apps/native-ui.
The preceding checks are successful: the app-side NS1063 issue in apps/native-ui/src/app.native was fixed, and native check apps/native-ui passes. native test apps/native-ui gets past that stage and then fails in the generated scriptc/Clang compilation.
Observed environment:
- Windows 11
- Node.js 24.18.0
- Zig 0.16.0
- LLVM/Clang 22.1.8
@native-sdk/cli@0.10.1
- the CLI-bundled
scriptc/@scriptc/compiler 0.0.35
The failure occurs while compiling the generated identity.c used for the library archive. It happens before linking; no native linker step or test runner is reached. The relevant diagnostic, with paths shortened, is:
.../LLVM/lib/clang/22/include/inttypes.h:24:15:
#include_next <inttypes.h>
^~~~~~~~~~~
fatal error: 'inttypes.h' file not found
The compiler is being invoked for the x86_64-windows-gnu host and target, but the matching path appears to select the native Clang/MSVC lane. Clang can find its built-in inttypes.h, but #include_next cannot find a usable Windows SDK header afterward.
Expected behavior
After the model contract check succeeds, native test apps/native-ui should compile the generated core and markup, link the Windows native test binary, and run the tests. If a complete MSVC/Windows SDK environment is required instead, the CLI should detect that prerequisite and report it clearly.
Actual behavior and impact
The generated identity.c compile stops on the missing inttypes.h before any app object is linked. This blocks Windows native tests and builds for TypeScript-core apps even though the app-side check is clean.
Possible fix direction
The target-selection logic in run_external_core_compiler.mjs and the corresponding service compiler path may need to send x86_64-windows-gnu through the Zig/zigcc lane when that is the requested target, instead of treating a matching host triple as the native Clang/MSVC lane. If the native lane is intended, it should select a complete clang-cl/Windows SDK environment and validate the required include directories before starting the generated compile.
Separate earlier observation: in an earlier run, the generated COFF build-obj graph also reported coff does not support linking multiple objects into one when the TypeScript core archive and markup object were attached together. That is a separate, later archive/linking problem; the reproduction above stops earlier while Clang is compiling identity.c, so the COFF message is not the cause of this missing-header failure.
This is related to #365, but this report narrows the failure down to the generated scriptc/Clang compile and the missing header.
Follow-up verification
A process-scoped workaround now discovers MSVC and Windows SDK include paths for the Native CLI compiler environment. This gets past the missing inttypes.h failure without adding fake headers or changing global compiler settings. The default Windows compiler lane still lacks those paths, so this remains an upstream issue.
A minimal public reproduction is available at:
https://github.com/mynameistito/native-sdk-coff-repro
From that checkout:
native check . --strict
native test .
native build .
After the header stage is bypassed, separate Zig/COFF linker failures occur, including unresolved _fltused, networking symbols, and:
coff does not support linking multiple objects into one
Those later failures are separate from this missing-header issue.
Automatically submitted on behalf of the user by an AI agent.
Reproduction
I am seeing this on Windows 11 with the Native SDK pinned to
@native-sdk/cli@0.10.1.From the repository root, run the Native CLI directly:
native check apps/native-ui native test apps/native-uiIf the CLI is not installed globally, the equivalent package-pinned invocation is:
bun x @native-sdk/cli@0.10.1 check apps/native-ui bun x @native-sdk/cli@0.10.1 test apps/native-uiThe repository convenience scripts are only an optional mapping of those commands:
The wrapper delegates to the same Native SDK CLI and adds repository-specific Windows environment setup; it is not required for the reproduction above.
That means
native test apps/native-uiinvokes the Native SDK CLItestcommand for the app. It first generates and compiles the model contract, then proceeds to the Windows native build. It is not failing in the application TypeScript tests or in the markup check.The Native CLI 0.10.1 also supports
native build [dir]; this report does not requirenative buildbecause the failing test path is reproduced bynative test apps/native-ui.The preceding checks are successful: the app-side
NS1063issue inapps/native-ui/src/app.nativewas fixed, andnative check apps/native-uipasses.native test apps/native-uigets past that stage and then fails in the generatedscriptc/Clang compilation.Observed environment:
@native-sdk/cli@0.10.1scriptc/@scriptc/compiler0.0.35The failure occurs while compiling the generated
identity.cused for the library archive. It happens before linking; no native linker step or test runner is reached. The relevant diagnostic, with paths shortened, is:The compiler is being invoked for the
x86_64-windows-gnuhost and target, but the matching path appears to select the native Clang/MSVC lane. Clang can find its built-ininttypes.h, but#include_nextcannot find a usable Windows SDK header afterward.Expected behavior
After the model contract check succeeds,
native test apps/native-uishould compile the generated core and markup, link the Windows native test binary, and run the tests. If a complete MSVC/Windows SDK environment is required instead, the CLI should detect that prerequisite and report it clearly.Actual behavior and impact
The generated
identity.ccompile stops on the missinginttypes.hbefore any app object is linked. This blocks Windows native tests and builds for TypeScript-core apps even though the app-side check is clean.Possible fix direction
The target-selection logic in
run_external_core_compiler.mjsand the corresponding service compiler path may need to sendx86_64-windows-gnuthrough the Zig/zigcc lane when that is the requested target, instead of treating a matching host triple as the native Clang/MSVC lane. If the native lane is intended, it should select a complete clang-cl/Windows SDK environment and validate the required include directories before starting the generated compile.Separate earlier observation: in an earlier run, the generated COFF
build-objgraph also reportedcoff does not support linking multiple objects into onewhen the TypeScript core archive and markup object were attached together. That is a separate, later archive/linking problem; the reproduction above stops earlier while Clang is compilingidentity.c, so the COFF message is not the cause of this missing-header failure.This is related to #365, but this report narrows the failure down to the generated
scriptc/Clang compile and the missing header.Follow-up verification
A process-scoped workaround now discovers MSVC and Windows SDK include paths for the Native CLI compiler environment. This gets past the missing
inttypes.hfailure without adding fake headers or changing global compiler settings. The default Windows compiler lane still lacks those paths, so this remains an upstream issue.A minimal public reproduction is available at:
https://github.com/mynameistito/native-sdk-coff-repro
From that checkout: