Repository navigation
Infer the web layer and enforce native-only builds end to end - #107
Merged
Merged
Conversation
- The build graph parses app.zon and strips the Windows webview layer, loader staging, and dev PATH wiring when nothing declares web use; a webview_layer manifest field and -Dweb-layer flag override inference in both directions - Conflicting declarations are rejected with one teaching message at validate, configure, runner compile, and package time, and a native-only build that reaches webview creation fails fast with WebViewLayerNotBuilt instead of a blank window - A PE cross-audit build step pins that native-only Windows exes never reference the loader while webview apps must, and native check prints the web-layer verdict Co-authored-by: WhiteHades <44260523+WhiteHades@users.noreply.github.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
- app_manifest.web_layer owns the declaration scan, engine folding, and include/exclude decision, usable at comptime by the runner and at runtime by the build graph, validator, CLI, and generated scaffolds, with boundary ownership documented where each adapter lives - Packaging decides from the resolved engine so --web-engine overrides cannot skew the layer, the runner guard covers shell views and manifest chromium, and the full scaffold emits the same inference, conflict panic, and conditional Windows wiring as the SDK graph - A contract matrix test runs every manifest shape through every boundary form so the definitions can never diverge again
- The capabilities page counts a Chromium-resolved engine as web intent and points at the override; the app.zon reference gains the webview_layer field, its inference and include/exclude semantics, and the exclude-conflict rule with the shipped error's remedy
- Both build graphs forward their computed web-layer decision to native package via a new --web-layer flag, so the exe and the package can never disagree; a confirming flag keeps the manifest's reason while an overriding one names itself - Packaging PE-scans Windows binaries and refuses to package a loader-referencing exe under a loaderless decision, closing the mismatch for hand-built binaries too - Fixes an adjacent buildgraph bug where a sentinel-terminated path allocation was returned as a plain slice
- NATIVE_SDK_ALLOW_WEBVIEW2_STUB now excludes the embedded layer even when WebView2 headers are globally visible, so a native-only build can never reintroduce the loader reference; the vendor pins lock the guard order - The stub message says the layer is excluded by configuration instead of claiming the header is missing
ctate
added a commit
that referenced
this pull request
Jul 11, 2026
Merged
ctate
added a commit
that referenced
this pull request
Jul 11, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Canvas apps carried the whole webview layer for nothing: WebView2 machinery and a staged
WebView2Loader.dllon Windows, frontend staging paths, and JS bridge dispatch — with no way to build a lean, honestly native-only binary. Community request (#84 framed it ashost = "native"); this lands the inference-first version so most apps get it with no declaration at all.What
app.zon— an app keeps the web layer iff it declares web use (afrontendblock, the"webview"capability, a shell webview view, or the chromium engine). Otherwise the Windows host compiles its stub layer, the loader is neither installed nor staged, dev PATH wiring is skipped, and packages ship lighter (~236 KB per Windows app).webview_layer = "auto" | "include" | "exclude"in the manifest (and-Dweb-layer), defaultautoexclude+ web declarations) are rejected with one consistent teaching message atnative validate, build configure, runner compile, and package time; a native-only build that reaches webview creation at runtime fails fast withWebViewLayerNotBuiltand the exact line to add — never a blank windownative checkand the package report print the web-layer verdict (web layer: none (inferred))Notes
Verification
Full suite, validate, examples battery, all seven smokes, PE audit both directions, and live checks of every enforcement boundary green.