Carry the TypeScript toolchain as a CLI dependency#123
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
ctate
force-pushed
the
fix/ts-transpiler-bootstrap
branch
from
6553c7f to
777e7be
Compare
ctate
changed the title
…endencies - @native-sdk/cli gains @typescript/typescript6 6.0.2 and @typescript/old npm:typescript@6.0.3 as regular dependencies, so npm installs the whole toolchain (the wrapper AND the real compiler it re-exports) in the same transaction as the CLI - packages/core pins the same two exact versions as devDependencies (replacing the ^6.0.2 range) and its lockfile follows - check-version-sync asserts both pins string-equal across the two manifests and shape-exact: X.Y.Z for the wrapper, npm:typescript@X.Y.Z for the alias
… layout - transpilerResolves walks node's ancestor node_modules from packages/core and requires the wrapper's manifest + entrypoint AND the aliased real compiler resolving from the wrapper's own directory (nested, hoisted, and global layouts alike); partial extractions read as unresolved - the gate runs before any zig spawn (check, dev --core, build-graph verbs) and never runs npm: checkouts (the packages/core/test signal) are taught the one npm ci --include=dev against a resolved absolute path, npm layouts are taught the reinstall (BrokenToolchainInstall) - build/app.zig carries the twin predicate for direct zig build and fails configure with a clean teaching instead of a panic; test-ts-toolchain-twins pins the twins' alias probes and teachings in lockstep
- first TS-verb use needs no network, no install step, and never runs npm - repo checkouts are taught the one npm ci command; direct zig build teaches instead of panicking
ctate
force-pushed
the
fix/ts-transpiler-bootstrap
branch
from
f6c72e3 to
0b2505a
Compare
- BrokenToolchainInstall already prints its reinstall guidance; list it in failVerb's expected-error switch so the CLI exits without a Zig error-return trace.
- Ejected apps pin their own SDK in build.zig.zon, so gating the CLI's resolved SDK false-failed healthy apps whose direct zig build works; they now flow to the spawn, where build/app.zig's tsCoreStage teaching names the app's actual dependency SDK. - Name the one generated-vs-ejected decision (isEjectedAt) so the preflight and the argv assembly share a single predicate, and keep check/dev --core gated: they always transpile against the CLI's SDK. - Cover both paths in a verbs test: an ejected-shaped TS layout skips the gate against a toolchain-less SDK; the generated layout still teaches, and passes once the toolchain resolves.
- ts_run.mjs now teaches "upgrade to Node.js 22.15+" and exits before importing a node_modules-resident target when module.registerHooks is missing, instead of dying inside node with the raw ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING; repo-checkout targets keep running natively on any Node 22. - Every "Node.js 22+" surface (nodeMissing teaching, build/app.zig panic, scaffold README, quick-start docs, changelog fragment) now names 22.15. - packages/core/test/ts_run.test.ts pins both tiers by spawning the runner with a --import preload that deletes module.registerHooks, plus the real hook-stripping path against the package's own toolchain install.
…mpiler - build/ts_run.mjs now strips ALL .ts modules (node's default stripping is 22.18+, so the 22.15-22.17 checkout fall-through died raw); hooks-absent teaches for any .ts target, and the hook requires @typescript/old directly with a sane direct-run teaching when the dev install is missing - typed_ast.ts imports @typescript/old instead of the wrapper, so a consumer tree's conflicting hoisted copy can never shadow the SDK's exact pin (the wrapper stays the declared dependency) - both resolution twins (ts_core.zig transpilerResolution, build/app.zig tsToolchainResolution) read the resolved @typescript/old version and hold it against the npm:typescript@X.Y.Z pin parsed from packages/core/package.json, teaching resolved-vs-pinned on mismatch; fixtures gain version/pin manifests and mismatch tests cover both layouts
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
…from - Both resolution twins now walk @typescript/old from packages/core — the origin typed_ast.ts and ts_run.mjs actually load from — instead of holding the wrapper's origin against the pin, which false-rejected npm's own conflict shape (consumer's hoisted compiler + our exact pin nested under the CLI); the unused @typescript/typescript6 wrapper is no longer probed at all, though it stays a declared dependency. - Make the node requirement branch-aware everywhere it is taught (22.15+ admits 23.0-23.4 numerically, but registerHooks only landed in 22.15 and 23.5): one phrasing across ts_run.mjs, both gate teachings, the templates README, the quick-start docs, and the changelog fragment. - Correct the changelog fragment's claim that repo checkouts run on any Node 22: every .ts module rides the same registerHooks stripping, so the floor is uniform across layouts.
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.
Fixes the one gap the 0.5.0 npm-channel funnel test found: a fresh
npm i @native-sdk/clicould not run any TypeScript verb — the published CLI carries thepackages/coretranspiler mirror, but npm never installs a nested package's devDependencies, so the toolchain was absent.native checkstopped at a manual-npm citeaching; the build-graph verbs delivered it viastd.debug.panic(stack trace, signal ABRT, mangled path).The fix: npm owns the install. The CLI declares its TypeScript toolchain as regular, exactly-pinned dependencies:
@typescript/typescript6@6.0.2— Microsoft's TS6-API continuity package (a one-line re-export), and@typescript/oldpinned tonpm:typescript@6.0.3— the real compiler behind the wrapper's caret alias, so consumer installs can never drift onto an untested compiler.check-version-syncasserts both pins string-equal across manifests and shape-exact (no ranges).zig buildgets a clean configure-time teaching with a resolved path and exit 1 — no panic.cd packages/core && npm ci --include=dev); an npm install missing its declared dependency is taught to reinstall the CLI. By design ruling, contributor paths get a teaching, not machinery — the CLI never runs npm at verb time on any layout.End-to-end proofs on the real
npm packartifact: fresh install → init/check/test/build zero-touch; the same funnel fully offline; achmod -R a-winstall byte-identical before/after (SHA-256 over every file);NODE_ENV=productionno effect; the checkout teaching fires without spawning anything; the panic path gone.Suites: full battery, validate, test-tooling (153/153, 4× flake check), test-ts-core-e2e, the new
test-ts-toolchain-twinspin step, packages/core npm suite 204/204, version:check in sync.