Windows GNU TypeScript-core builds select host Clang and fail on missing inttypes.h

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.

Reproduce the failure with native test apps/native-ui or the package-pinned command, then inspect target-selection logic in run_external_core_compiler.mjs and the corresponding service compiler path. Start by tracing how x86_64-windows-gnu is routed and how Windows include paths are established. Done means the generated identity.c compilation proceeds with a valid toolchain, allowing the native test build and runner to complete.