capnweb-validate: ship typescript as a capped dependency by Maximo-Guk · Pull Request #240 · cloudflare/capnweb

Maximo-Guk · 2026-08-12T19:28:37Z

capnweb-validate's build-time transform needs the JS compiler API (transpileModule, createProgram, ts.sys), which TypeScript 7 (tsgo) no longer ships. The current peer is uncapped (>=5.7.0), so in a workspace whose typescript is 7.x the transform resolves a metadata-only package and dies at build time (ts.sys / ts.findConfigFile undefined). Working around it consumer-side takes a .pnpmfile.cjs hook, because pnpm resolves peers from the importer's context and neither overrides nor packageExtensions can move one.

This swaps the peer for a real dependency capped at <7: under a TS 7 workspace the transform gets its own JS-based compiler (transform compiler and check compiler are independent - checking with tsgo still works fine), and consumers on 5.7–6.x dedupe to their existing install. The 6.0.3 compiler is validated against the transform in a real consumer.

changeset-bot · 2026-08-12T19:28:41Z

🦋 Changeset detected

Latest commit: af74f4d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb-validate	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-12T19:29:18Z

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@240

commit: af74f4d

The transform needs the JS compiler API, which TypeScript 7 (tsgo) no longer ships. The uncapped peer (>=5.7.0) resolved to whatever the consumer's workspace has, so under a TS 7 workspace the transform got a metadata-only package and crashed at build time; consumers had to work around it with a .pnpmfile.cjs rewriting the peer. A real dependency capped at <7 gives the transform its own JS-based compiler under TS 7 workspaces (transform compiler and check compiler are independent), and dedupes against the consumer's install on 5.7-6.x. The lockfile diff is hand-minimized because npm 11.9 strips the libc fields a newer npm wrote; npm ci validates it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

teamchong · 2026-08-12T20:16:40Z

/bonk review this

ask-bonk

Review: ship typescript as a capped dependency

The change is sound and correctly targeted. The root cause analysis is accurate: capnweb-validate's transform imports the typescript compiler API at build time (import ts from "typescript" in src/transform/{run,context,transform-module}.ts), and those entry points call ts.sys / ts.findConfigFile / transpileModule / createProgram — none of which exist in the metadata-only TS 7 (tsgo) package. Moving typescript from an uncapped peer to a >=5.7.0 <7 direct dependency guarantees a real JS compiler is present regardless of the workspace's TS version, and consumers on 5.7–6.x will dedupe.

Consistency check (all good)

package.json and the lockfile agree: dependencies.typescript = ">=5.7.0 <7", peer removed, devDep removed.
Resolved lockfile version 5.9.3 satisfies the new range and is no longer marked dev.
Root workspace still declares typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points worth confirming before merge

Trade-off is a real duplicate install for TS 7 consumers. Under a TS 7 workspace, <7 forces a second, JS-based TypeScript (6.x) to be installed alongside the consumer's tsgo. That's the intended behavior and is stated in the PR body, but it's worth flagging explicitly for reviewers: this is a deliberate on-disk cost, not a bug.
import type ts from "typescript" in type-introspector.ts is type-only and would have been erased — so the runtime need is genuinely the three value-importing modules. No concern, just confirming the peer->dep move is necessary rather than cosmetic.
Making typescript a hard dependencies rather than an optional peer changes install semantics for all consumers, including any who only use the runtime ./internal exports and never the build-time transform. Those consumers will now always pull a TypeScript copy. If there is a runtime-only consumption path that never touches the compiler, consider whether typescript could instead be a capped peer (>=5.7.0 <7) so it stays out of pure-runtime installs. If the package is only ever consumed as a build-time transform, the direct dependency is the right call and this is a non-issue.

Nothing blocking from a correctness standpoint. Items 1 and 3 are design confirmations rather than defects.

ask-bonk · 2026-08-12T20:18:03Z

Review posted successfully. Summary of my assessment of PR #240:

Verdict: sound and correctly targeted, no blocking issues.

The change moves typescript from an uncapped peer dependency to a capped direct dependency (>=5.7.0 <7) on capnweb-validate.

What I verified:

The root cause is real — the transform value-imports the TS compiler API (ts.sys, findConfigFile, transpileModule, createProgram) in src/transform/{run,context,transform-module}.ts, which TS 7 (tsgo) doesn't ship.
package.json and package-lock.json are internally consistent (dep added, peer removed, devDep removed, dev: true flag dropped, resolved 5.9.3 satisfies the range).
Root workspace still has typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points I flagged for the maintainer (design confirmations, not defects):

The <7 cap deliberately forces a duplicate JS-based TS install for TS 7 consumers — intended, but worth noting.
type-introspector.ts uses a type-only import, confirming the runtime need is genuine.
A hard dependencies entry means even runtime-only (./internal) consumers now always pull TypeScript; if such a path exists, a capped peer might be preferable — otherwise the direct dependency is correct.

github run

Maximo-Guk · 2026-08-12T19:28:37Z

capnweb-validate's build-time transform needs the JS compiler API (transpileModule, createProgram, ts.sys), which TypeScript 7 (tsgo) no longer ships. The current peer is uncapped (>=5.7.0), so in a workspace whose typescript is 7.x the transform resolves a metadata-only package and dies at build time (ts.sys / ts.findConfigFile undefined). Working around it consumer-side takes a .pnpmfile.cjs hook, because pnpm resolves peers from the importer's context and neither overrides nor packageExtensions can move one.

This swaps the peer for a real dependency capped at <7: under a TS 7 workspace the transform gets its own JS-based compiler (transform compiler and check compiler are independent - checking with tsgo still works fine), and consumers on 5.7–6.x dedupe to their existing install. The 6.0.3 compiler is validated against the transform in a real consumer.

changeset-bot · 2026-08-12T19:28:41Z

🦋 Changeset detected

Latest commit: af74f4d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb-validate	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-12T19:29:18Z

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@240

commit: af74f4d

The transform needs the JS compiler API, which TypeScript 7 (tsgo) no longer ships. The uncapped peer (>=5.7.0) resolved to whatever the consumer's workspace has, so under a TS 7 workspace the transform got a metadata-only package and crashed at build time; consumers had to work around it with a .pnpmfile.cjs rewriting the peer. A real dependency capped at <7 gives the transform its own JS-based compiler under TS 7 workspaces (transform compiler and check compiler are independent), and dedupes against the consumer's install on 5.7-6.x. The lockfile diff is hand-minimized because npm 11.9 strips the libc fields a newer npm wrote; npm ci validates it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

teamchong · 2026-08-12T20:16:40Z

/bonk review this

ask-bonk

Review: ship typescript as a capped dependency

The change is sound and correctly targeted. The root cause analysis is accurate: capnweb-validate's transform imports the typescript compiler API at build time (import ts from "typescript" in src/transform/{run,context,transform-module}.ts), and those entry points call ts.sys / ts.findConfigFile / transpileModule / createProgram — none of which exist in the metadata-only TS 7 (tsgo) package. Moving typescript from an uncapped peer to a >=5.7.0 <7 direct dependency guarantees a real JS compiler is present regardless of the workspace's TS version, and consumers on 5.7–6.x will dedupe.

Consistency check (all good)

package.json and the lockfile agree: dependencies.typescript = ">=5.7.0 <7", peer removed, devDep removed.
Resolved lockfile version 5.9.3 satisfies the new range and is no longer marked dev.
Root workspace still declares typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points worth confirming before merge

Trade-off is a real duplicate install for TS 7 consumers. Under a TS 7 workspace, <7 forces a second, JS-based TypeScript (6.x) to be installed alongside the consumer's tsgo. That's the intended behavior and is stated in the PR body, but it's worth flagging explicitly for reviewers: this is a deliberate on-disk cost, not a bug.
import type ts from "typescript" in type-introspector.ts is type-only and would have been erased — so the runtime need is genuinely the three value-importing modules. No concern, just confirming the peer->dep move is necessary rather than cosmetic.
Making typescript a hard dependencies rather than an optional peer changes install semantics for all consumers, including any who only use the runtime ./internal exports and never the build-time transform. Those consumers will now always pull a TypeScript copy. If there is a runtime-only consumption path that never touches the compiler, consider whether typescript could instead be a capped peer (>=5.7.0 <7) so it stays out of pure-runtime installs. If the package is only ever consumed as a build-time transform, the direct dependency is the right call and this is a non-issue.

Nothing blocking from a correctness standpoint. Items 1 and 3 are design confirmations rather than defects.

ask-bonk · 2026-08-12T20:18:03Z

Review posted successfully. Summary of my assessment of PR #240:

Verdict: sound and correctly targeted, no blocking issues.

The change moves typescript from an uncapped peer dependency to a capped direct dependency (>=5.7.0 <7) on capnweb-validate.

What I verified:

The root cause is real — the transform value-imports the TS compiler API (ts.sys, findConfigFile, transpileModule, createProgram) in src/transform/{run,context,transform-module}.ts, which TS 7 (tsgo) doesn't ship.
package.json and package-lock.json are internally consistent (dep added, peer removed, devDep removed, dev: true flag dropped, resolved 5.9.3 satisfies the range).
Root workspace still has typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points I flagged for the maintainer (design confirmations, not defects):

The <7 cap deliberately forces a duplicate JS-based TS install for TS 7 consumers — intended, but worth noting.
type-introspector.ts uses a type-only import, confirming the runtime need is genuine.
A hard dependencies entry means even runtime-only (./internal) consumers now always pull TypeScript; if such a path exists, a capped peer might be preferable — otherwise the direct dependency is correct.

github run

Maximo-Guk · 2026-08-12T19:28:37Z

capnweb-validate's build-time transform needs the JS compiler API (transpileModule, createProgram, ts.sys), which TypeScript 7 (tsgo) no longer ships. The current peer is uncapped (>=5.7.0), so in a workspace whose typescript is 7.x the transform resolves a metadata-only package and dies at build time (ts.sys / ts.findConfigFile undefined). Working around it consumer-side takes a .pnpmfile.cjs hook, because pnpm resolves peers from the importer's context and neither overrides nor packageExtensions can move one.

This swaps the peer for a real dependency capped at <7: under a TS 7 workspace the transform gets its own JS-based compiler (transform compiler and check compiler are independent - checking with tsgo still works fine), and consumers on 5.7–6.x dedupe to their existing install. The 6.0.3 compiler is validated against the transform in a real consumer.

changeset-bot · 2026-08-12T19:28:41Z

🦋 Changeset detected

Latest commit: af74f4d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb-validate	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-12T19:29:18Z

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@240

commit: af74f4d

The transform needs the JS compiler API, which TypeScript 7 (tsgo) no longer ships. The uncapped peer (>=5.7.0) resolved to whatever the consumer's workspace has, so under a TS 7 workspace the transform got a metadata-only package and crashed at build time; consumers had to work around it with a .pnpmfile.cjs rewriting the peer. A real dependency capped at <7 gives the transform its own JS-based compiler under TS 7 workspaces (transform compiler and check compiler are independent), and dedupes against the consumer's install on 5.7-6.x. The lockfile diff is hand-minimized because npm 11.9 strips the libc fields a newer npm wrote; npm ci validates it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

teamchong · 2026-08-12T20:16:40Z

/bonk review this

ask-bonk

Review: ship typescript as a capped dependency

The change is sound and correctly targeted. The root cause analysis is accurate: capnweb-validate's transform imports the typescript compiler API at build time (import ts from "typescript" in src/transform/{run,context,transform-module}.ts), and those entry points call ts.sys / ts.findConfigFile / transpileModule / createProgram — none of which exist in the metadata-only TS 7 (tsgo) package. Moving typescript from an uncapped peer to a >=5.7.0 <7 direct dependency guarantees a real JS compiler is present regardless of the workspace's TS version, and consumers on 5.7–6.x will dedupe.

Consistency check (all good)

package.json and the lockfile agree: dependencies.typescript = ">=5.7.0 <7", peer removed, devDep removed.
Resolved lockfile version 5.9.3 satisfies the new range and is no longer marked dev.
Root workspace still declares typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points worth confirming before merge

Trade-off is a real duplicate install for TS 7 consumers. Under a TS 7 workspace, <7 forces a second, JS-based TypeScript (6.x) to be installed alongside the consumer's tsgo. That's the intended behavior and is stated in the PR body, but it's worth flagging explicitly for reviewers: this is a deliberate on-disk cost, not a bug.
import type ts from "typescript" in type-introspector.ts is type-only and would have been erased — so the runtime need is genuinely the three value-importing modules. No concern, just confirming the peer->dep move is necessary rather than cosmetic.
Making typescript a hard dependencies rather than an optional peer changes install semantics for all consumers, including any who only use the runtime ./internal exports and never the build-time transform. Those consumers will now always pull a TypeScript copy. If there is a runtime-only consumption path that never touches the compiler, consider whether typescript could instead be a capped peer (>=5.7.0 <7) so it stays out of pure-runtime installs. If the package is only ever consumed as a build-time transform, the direct dependency is the right call and this is a non-issue.

Nothing blocking from a correctness standpoint. Items 1 and 3 are design confirmations rather than defects.

ask-bonk · 2026-08-12T20:18:03Z

Review posted successfully. Summary of my assessment of PR #240:

Verdict: sound and correctly targeted, no blocking issues.

The change moves typescript from an uncapped peer dependency to a capped direct dependency (>=5.7.0 <7) on capnweb-validate.

What I verified:

The root cause is real — the transform value-imports the TS compiler API (ts.sys, findConfigFile, transpileModule, createProgram) in src/transform/{run,context,transform-module}.ts, which TS 7 (tsgo) doesn't ship.
package.json and package-lock.json are internally consistent (dep added, peer removed, devDep removed, dev: true flag dropped, resolved 5.9.3 satisfies the range).
Root workspace still has typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points I flagged for the maintainer (design confirmations, not defects):

The <7 cap deliberately forces a duplicate JS-based TS install for TS 7 consumers — intended, but worth noting.
type-introspector.ts uses a type-only import, confirming the runtime need is genuine.
A hard dependencies entry means even runtime-only (./internal) consumers now always pull TypeScript; if such a path exists, a capped peer might be preferable — otherwise the direct dependency is correct.

github run

Maximo-Guk · 2026-08-12T19:28:37Z

capnweb-validate's build-time transform needs the JS compiler API (transpileModule, createProgram, ts.sys), which TypeScript 7 (tsgo) no longer ships. The current peer is uncapped (>=5.7.0), so in a workspace whose typescript is 7.x the transform resolves a metadata-only package and dies at build time (ts.sys / ts.findConfigFile undefined). Working around it consumer-side takes a .pnpmfile.cjs hook, because pnpm resolves peers from the importer's context and neither overrides nor packageExtensions can move one.

This swaps the peer for a real dependency capped at <7: under a TS 7 workspace the transform gets its own JS-based compiler (transform compiler and check compiler are independent - checking with tsgo still works fine), and consumers on 5.7–6.x dedupe to their existing install. The 6.0.3 compiler is validated against the transform in a real consumer.

changeset-bot · 2026-08-12T19:28:41Z

🦋 Changeset detected

Latest commit: af74f4d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb-validate	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-12T19:29:18Z

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@240

commit: af74f4d

The transform needs the JS compiler API, which TypeScript 7 (tsgo) no longer ships. The uncapped peer (>=5.7.0) resolved to whatever the consumer's workspace has, so under a TS 7 workspace the transform got a metadata-only package and crashed at build time; consumers had to work around it with a .pnpmfile.cjs rewriting the peer. A real dependency capped at <7 gives the transform its own JS-based compiler under TS 7 workspaces (transform compiler and check compiler are independent), and dedupes against the consumer's install on 5.7-6.x. The lockfile diff is hand-minimized because npm 11.9 strips the libc fields a newer npm wrote; npm ci validates it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

teamchong · 2026-08-12T20:16:40Z

/bonk review this

ask-bonk

Review: ship typescript as a capped dependency

The change is sound and correctly targeted. The root cause analysis is accurate: capnweb-validate's transform imports the typescript compiler API at build time (import ts from "typescript" in src/transform/{run,context,transform-module}.ts), and those entry points call ts.sys / ts.findConfigFile / transpileModule / createProgram — none of which exist in the metadata-only TS 7 (tsgo) package. Moving typescript from an uncapped peer to a >=5.7.0 <7 direct dependency guarantees a real JS compiler is present regardless of the workspace's TS version, and consumers on 5.7–6.x will dedupe.

Consistency check (all good)

package.json and the lockfile agree: dependencies.typescript = ">=5.7.0 <7", peer removed, devDep removed.
Resolved lockfile version 5.9.3 satisfies the new range and is no longer marked dev.
Root workspace still declares typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points worth confirming before merge

Trade-off is a real duplicate install for TS 7 consumers. Under a TS 7 workspace, <7 forces a second, JS-based TypeScript (6.x) to be installed alongside the consumer's tsgo. That's the intended behavior and is stated in the PR body, but it's worth flagging explicitly for reviewers: this is a deliberate on-disk cost, not a bug.
import type ts from "typescript" in type-introspector.ts is type-only and would have been erased — so the runtime need is genuinely the three value-importing modules. No concern, just confirming the peer->dep move is necessary rather than cosmetic.
Making typescript a hard dependencies rather than an optional peer changes install semantics for all consumers, including any who only use the runtime ./internal exports and never the build-time transform. Those consumers will now always pull a TypeScript copy. If there is a runtime-only consumption path that never touches the compiler, consider whether typescript could instead be a capped peer (>=5.7.0 <7) so it stays out of pure-runtime installs. If the package is only ever consumed as a build-time transform, the direct dependency is the right call and this is a non-issue.

Nothing blocking from a correctness standpoint. Items 1 and 3 are design confirmations rather than defects.

ask-bonk · 2026-08-12T20:18:03Z

Review posted successfully. Summary of my assessment of PR #240:

Verdict: sound and correctly targeted, no blocking issues.

The change moves typescript from an uncapped peer dependency to a capped direct dependency (>=5.7.0 <7) on capnweb-validate.

What I verified:

The root cause is real — the transform value-imports the TS compiler API (ts.sys, findConfigFile, transpileModule, createProgram) in src/transform/{run,context,transform-module}.ts, which TS 7 (tsgo) doesn't ship.
package.json and package-lock.json are internally consistent (dep added, peer removed, devDep removed, dev: true flag dropped, resolved 5.9.3 satisfies the range).
Root workspace still has typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points I flagged for the maintainer (design confirmations, not defects):

The <7 cap deliberately forces a duplicate JS-based TS install for TS 7 consumers — intended, but worth noting.
type-introspector.ts uses a type-only import, confirming the runtime need is genuine.
A hard dependencies entry means even runtime-only (./internal) consumers now always pull TypeScript; if such a path exists, a capped peer might be preferable — otherwise the direct dependency is correct.

github run

Maximo-Guk · 2026-08-12T19:28:37Z

capnweb-validate's build-time transform needs the JS compiler API (transpileModule, createProgram, ts.sys), which TypeScript 7 (tsgo) no longer ships. The current peer is uncapped (>=5.7.0), so in a workspace whose typescript is 7.x the transform resolves a metadata-only package and dies at build time (ts.sys / ts.findConfigFile undefined). Working around it consumer-side takes a .pnpmfile.cjs hook, because pnpm resolves peers from the importer's context and neither overrides nor packageExtensions can move one.

This swaps the peer for a real dependency capped at <7: under a TS 7 workspace the transform gets its own JS-based compiler (transform compiler and check compiler are independent - checking with tsgo still works fine), and consumers on 5.7–6.x dedupe to their existing install. The 6.0.3 compiler is validated against the transform in a real consumer.

changeset-bot · 2026-08-12T19:28:41Z

🦋 Changeset detected

Latest commit: af74f4d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb-validate	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-12T19:29:18Z

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@240

commit: af74f4d

The transform needs the JS compiler API, which TypeScript 7 (tsgo) no longer ships. The uncapped peer (>=5.7.0) resolved to whatever the consumer's workspace has, so under a TS 7 workspace the transform got a metadata-only package and crashed at build time; consumers had to work around it with a .pnpmfile.cjs rewriting the peer. A real dependency capped at <7 gives the transform its own JS-based compiler under TS 7 workspaces (transform compiler and check compiler are independent), and dedupes against the consumer's install on 5.7-6.x. The lockfile diff is hand-minimized because npm 11.9 strips the libc fields a newer npm wrote; npm ci validates it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

teamchong · 2026-08-12T20:16:40Z

/bonk review this

ask-bonk

Review: ship typescript as a capped dependency

The change is sound and correctly targeted. The root cause analysis is accurate: capnweb-validate's transform imports the typescript compiler API at build time (import ts from "typescript" in src/transform/{run,context,transform-module}.ts), and those entry points call ts.sys / ts.findConfigFile / transpileModule / createProgram — none of which exist in the metadata-only TS 7 (tsgo) package. Moving typescript from an uncapped peer to a >=5.7.0 <7 direct dependency guarantees a real JS compiler is present regardless of the workspace's TS version, and consumers on 5.7–6.x will dedupe.

Consistency check (all good)

package.json and the lockfile agree: dependencies.typescript = ">=5.7.0 <7", peer removed, devDep removed.
Resolved lockfile version 5.9.3 satisfies the new range and is no longer marked dev.
Root workspace still declares typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points worth confirming before merge

Trade-off is a real duplicate install for TS 7 consumers. Under a TS 7 workspace, <7 forces a second, JS-based TypeScript (6.x) to be installed alongside the consumer's tsgo. That's the intended behavior and is stated in the PR body, but it's worth flagging explicitly for reviewers: this is a deliberate on-disk cost, not a bug.
import type ts from "typescript" in type-introspector.ts is type-only and would have been erased — so the runtime need is genuinely the three value-importing modules. No concern, just confirming the peer->dep move is necessary rather than cosmetic.
Making typescript a hard dependencies rather than an optional peer changes install semantics for all consumers, including any who only use the runtime ./internal exports and never the build-time transform. Those consumers will now always pull a TypeScript copy. If there is a runtime-only consumption path that never touches the compiler, consider whether typescript could instead be a capped peer (>=5.7.0 <7) so it stays out of pure-runtime installs. If the package is only ever consumed as a build-time transform, the direct dependency is the right call and this is a non-issue.

Nothing blocking from a correctness standpoint. Items 1 and 3 are design confirmations rather than defects.

ask-bonk · 2026-08-12T20:18:03Z

Review posted successfully. Summary of my assessment of PR #240:

Verdict: sound and correctly targeted, no blocking issues.

The change moves typescript from an uncapped peer dependency to a capped direct dependency (>=5.7.0 <7) on capnweb-validate.

What I verified:

The root cause is real — the transform value-imports the TS compiler API (ts.sys, findConfigFile, transpileModule, createProgram) in src/transform/{run,context,transform-module}.ts, which TS 7 (tsgo) doesn't ship.
package.json and package-lock.json are internally consistent (dep added, peer removed, devDep removed, dev: true flag dropped, resolved 5.9.3 satisfies the range).
Root workspace still has typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points I flagged for the maintainer (design confirmations, not defects):

The <7 cap deliberately forces a duplicate JS-based TS install for TS 7 consumers — intended, but worth noting.
type-introspector.ts uses a type-only import, confirming the runtime need is genuine.
A hard dependencies entry means even runtime-only (./internal) consumers now always pull TypeScript; if such a path exists, a capped peer might be preferable — otherwise the direct dependency is correct.

github run

Maximo-Guk · 2026-08-12T19:28:37Z

capnweb-validate's build-time transform needs the JS compiler API (transpileModule, createProgram, ts.sys), which TypeScript 7 (tsgo) no longer ships. The current peer is uncapped (>=5.7.0), so in a workspace whose typescript is 7.x the transform resolves a metadata-only package and dies at build time (ts.sys / ts.findConfigFile undefined). Working around it consumer-side takes a .pnpmfile.cjs hook, because pnpm resolves peers from the importer's context and neither overrides nor packageExtensions can move one.

This swaps the peer for a real dependency capped at <7: under a TS 7 workspace the transform gets its own JS-based compiler (transform compiler and check compiler are independent - checking with tsgo still works fine), and consumers on 5.7–6.x dedupe to their existing install. The 6.0.3 compiler is validated against the transform in a real consumer.

changeset-bot · 2026-08-12T19:28:41Z

🦋 Changeset detected

Latest commit: af74f4d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb-validate	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-12T19:29:18Z

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@240

commit: af74f4d

The transform needs the JS compiler API, which TypeScript 7 (tsgo) no longer ships. The uncapped peer (>=5.7.0) resolved to whatever the consumer's workspace has, so under a TS 7 workspace the transform got a metadata-only package and crashed at build time; consumers had to work around it with a .pnpmfile.cjs rewriting the peer. A real dependency capped at <7 gives the transform its own JS-based compiler under TS 7 workspaces (transform compiler and check compiler are independent), and dedupes against the consumer's install on 5.7-6.x. The lockfile diff is hand-minimized because npm 11.9 strips the libc fields a newer npm wrote; npm ci validates it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

teamchong · 2026-08-12T20:16:40Z

/bonk review this

ask-bonk

Review: ship typescript as a capped dependency

The change is sound and correctly targeted. The root cause analysis is accurate: capnweb-validate's transform imports the typescript compiler API at build time (import ts from "typescript" in src/transform/{run,context,transform-module}.ts), and those entry points call ts.sys / ts.findConfigFile / transpileModule / createProgram — none of which exist in the metadata-only TS 7 (tsgo) package. Moving typescript from an uncapped peer to a >=5.7.0 <7 direct dependency guarantees a real JS compiler is present regardless of the workspace's TS version, and consumers on 5.7–6.x will dedupe.

Consistency check (all good)

package.json and the lockfile agree: dependencies.typescript = ">=5.7.0 <7", peer removed, devDep removed.
Resolved lockfile version 5.9.3 satisfies the new range and is no longer marked dev.
Root workspace still declares typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points worth confirming before merge

Trade-off is a real duplicate install for TS 7 consumers. Under a TS 7 workspace, <7 forces a second, JS-based TypeScript (6.x) to be installed alongside the consumer's tsgo. That's the intended behavior and is stated in the PR body, but it's worth flagging explicitly for reviewers: this is a deliberate on-disk cost, not a bug.
import type ts from "typescript" in type-introspector.ts is type-only and would have been erased — so the runtime need is genuinely the three value-importing modules. No concern, just confirming the peer->dep move is necessary rather than cosmetic.
Making typescript a hard dependencies rather than an optional peer changes install semantics for all consumers, including any who only use the runtime ./internal exports and never the build-time transform. Those consumers will now always pull a TypeScript copy. If there is a runtime-only consumption path that never touches the compiler, consider whether typescript could instead be a capped peer (>=5.7.0 <7) so it stays out of pure-runtime installs. If the package is only ever consumed as a build-time transform, the direct dependency is the right call and this is a non-issue.

Nothing blocking from a correctness standpoint. Items 1 and 3 are design confirmations rather than defects.

ask-bonk · 2026-08-12T20:18:03Z

Review posted successfully. Summary of my assessment of PR #240:

Verdict: sound and correctly targeted, no blocking issues.

The change moves typescript from an uncapped peer dependency to a capped direct dependency (>=5.7.0 <7) on capnweb-validate.

What I verified:

The root cause is real — the transform value-imports the TS compiler API (ts.sys, findConfigFile, transpileModule, createProgram) in src/transform/{run,context,transform-module}.ts, which TS 7 (tsgo) doesn't ship.
package.json and package-lock.json are internally consistent (dep added, peer removed, devDep removed, dev: true flag dropped, resolved 5.9.3 satisfies the range).
Root workspace still has typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points I flagged for the maintainer (design confirmations, not defects):

The <7 cap deliberately forces a duplicate JS-based TS install for TS 7 consumers — intended, but worth noting.
type-introspector.ts uses a type-only import, confirming the runtime need is genuine.
A hard dependencies entry means even runtime-only (./internal) consumers now always pull TypeScript; if such a path exists, a capped peer might be preferable — otherwise the direct dependency is correct.

github run

Maximo-Guk · 2026-08-12T19:28:37Z

capnweb-validate's build-time transform needs the JS compiler API (transpileModule, createProgram, ts.sys), which TypeScript 7 (tsgo) no longer ships. The current peer is uncapped (>=5.7.0), so in a workspace whose typescript is 7.x the transform resolves a metadata-only package and dies at build time (ts.sys / ts.findConfigFile undefined). Working around it consumer-side takes a .pnpmfile.cjs hook, because pnpm resolves peers from the importer's context and neither overrides nor packageExtensions can move one.

This swaps the peer for a real dependency capped at <7: under a TS 7 workspace the transform gets its own JS-based compiler (transform compiler and check compiler are independent - checking with tsgo still works fine), and consumers on 5.7–6.x dedupe to their existing install. The 6.0.3 compiler is validated against the transform in a real consumer.

changeset-bot · 2026-08-12T19:28:41Z

🦋 Changeset detected

Latest commit: af74f4d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb-validate	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-12T19:29:18Z

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@240

commit: af74f4d

The transform needs the JS compiler API, which TypeScript 7 (tsgo) no longer ships. The uncapped peer (>=5.7.0) resolved to whatever the consumer's workspace has, so under a TS 7 workspace the transform got a metadata-only package and crashed at build time; consumers had to work around it with a .pnpmfile.cjs rewriting the peer. A real dependency capped at <7 gives the transform its own JS-based compiler under TS 7 workspaces (transform compiler and check compiler are independent), and dedupes against the consumer's install on 5.7-6.x. The lockfile diff is hand-minimized because npm 11.9 strips the libc fields a newer npm wrote; npm ci validates it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

teamchong · 2026-08-12T20:16:40Z

/bonk review this

ask-bonk

Review: ship typescript as a capped dependency

The change is sound and correctly targeted. The root cause analysis is accurate: capnweb-validate's transform imports the typescript compiler API at build time (import ts from "typescript" in src/transform/{run,context,transform-module}.ts), and those entry points call ts.sys / ts.findConfigFile / transpileModule / createProgram — none of which exist in the metadata-only TS 7 (tsgo) package. Moving typescript from an uncapped peer to a >=5.7.0 <7 direct dependency guarantees a real JS compiler is present regardless of the workspace's TS version, and consumers on 5.7–6.x will dedupe.

Consistency check (all good)

package.json and the lockfile agree: dependencies.typescript = ">=5.7.0 <7", peer removed, devDep removed.
Resolved lockfile version 5.9.3 satisfies the new range and is no longer marked dev.
Root workspace still declares typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points worth confirming before merge

Trade-off is a real duplicate install for TS 7 consumers. Under a TS 7 workspace, <7 forces a second, JS-based TypeScript (6.x) to be installed alongside the consumer's tsgo. That's the intended behavior and is stated in the PR body, but it's worth flagging explicitly for reviewers: this is a deliberate on-disk cost, not a bug.
import type ts from "typescript" in type-introspector.ts is type-only and would have been erased — so the runtime need is genuinely the three value-importing modules. No concern, just confirming the peer->dep move is necessary rather than cosmetic.
Making typescript a hard dependencies rather than an optional peer changes install semantics for all consumers, including any who only use the runtime ./internal exports and never the build-time transform. Those consumers will now always pull a TypeScript copy. If there is a runtime-only consumption path that never touches the compiler, consider whether typescript could instead be a capped peer (>=5.7.0 <7) so it stays out of pure-runtime installs. If the package is only ever consumed as a build-time transform, the direct dependency is the right call and this is a non-issue.

Nothing blocking from a correctness standpoint. Items 1 and 3 are design confirmations rather than defects.

ask-bonk · 2026-08-12T20:18:03Z

Review posted successfully. Summary of my assessment of PR #240:

Verdict: sound and correctly targeted, no blocking issues.

The change moves typescript from an uncapped peer dependency to a capped direct dependency (>=5.7.0 <7) on capnweb-validate.

What I verified:

The root cause is real — the transform value-imports the TS compiler API (ts.sys, findConfigFile, transpileModule, createProgram) in src/transform/{run,context,transform-module}.ts, which TS 7 (tsgo) doesn't ship.
package.json and package-lock.json are internally consistent (dep added, peer removed, devDep removed, dev: true flag dropped, resolved 5.9.3 satisfies the range).
Root workspace still has typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points I flagged for the maintainer (design confirmations, not defects):

The <7 cap deliberately forces a duplicate JS-based TS install for TS 7 consumers — intended, but worth noting.
type-introspector.ts uses a type-only import, confirming the runtime need is genuine.
A hard dependencies entry means even runtime-only (./internal) consumers now always pull TypeScript; if such a path exists, a capped peer might be preferable — otherwise the direct dependency is correct.

github run

Maximo-Guk · 2026-08-12T19:28:37Z

capnweb-validate's build-time transform needs the JS compiler API (transpileModule, createProgram, ts.sys), which TypeScript 7 (tsgo) no longer ships. The current peer is uncapped (>=5.7.0), so in a workspace whose typescript is 7.x the transform resolves a metadata-only package and dies at build time (ts.sys / ts.findConfigFile undefined). Working around it consumer-side takes a .pnpmfile.cjs hook, because pnpm resolves peers from the importer's context and neither overrides nor packageExtensions can move one.

This swaps the peer for a real dependency capped at <7: under a TS 7 workspace the transform gets its own JS-based compiler (transform compiler and check compiler are independent - checking with tsgo still works fine), and consumers on 5.7–6.x dedupe to their existing install. The 6.0.3 compiler is validated against the transform in a real consumer.

changeset-bot · 2026-08-12T19:28:41Z

🦋 Changeset detected

Latest commit: af74f4d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb-validate	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-12T19:29:18Z

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@240

commit: af74f4d

The transform needs the JS compiler API, which TypeScript 7 (tsgo) no longer ships. The uncapped peer (>=5.7.0) resolved to whatever the consumer's workspace has, so under a TS 7 workspace the transform got a metadata-only package and crashed at build time; consumers had to work around it with a .pnpmfile.cjs rewriting the peer. A real dependency capped at <7 gives the transform its own JS-based compiler under TS 7 workspaces (transform compiler and check compiler are independent), and dedupes against the consumer's install on 5.7-6.x. The lockfile diff is hand-minimized because npm 11.9 strips the libc fields a newer npm wrote; npm ci validates it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

teamchong · 2026-08-12T20:16:40Z

/bonk review this

ask-bonk

Review: ship typescript as a capped dependency

The change is sound and correctly targeted. The root cause analysis is accurate: capnweb-validate's transform imports the typescript compiler API at build time (import ts from "typescript" in src/transform/{run,context,transform-module}.ts), and those entry points call ts.sys / ts.findConfigFile / transpileModule / createProgram — none of which exist in the metadata-only TS 7 (tsgo) package. Moving typescript from an uncapped peer to a >=5.7.0 <7 direct dependency guarantees a real JS compiler is present regardless of the workspace's TS version, and consumers on 5.7–6.x will dedupe.

Consistency check (all good)

package.json and the lockfile agree: dependencies.typescript = ">=5.7.0 <7", peer removed, devDep removed.
Resolved lockfile version 5.9.3 satisfies the new range and is no longer marked dev.
Root workspace still declares typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points worth confirming before merge

Trade-off is a real duplicate install for TS 7 consumers. Under a TS 7 workspace, <7 forces a second, JS-based TypeScript (6.x) to be installed alongside the consumer's tsgo. That's the intended behavior and is stated in the PR body, but it's worth flagging explicitly for reviewers: this is a deliberate on-disk cost, not a bug.
import type ts from "typescript" in type-introspector.ts is type-only and would have been erased — so the runtime need is genuinely the three value-importing modules. No concern, just confirming the peer->dep move is necessary rather than cosmetic.
Making typescript a hard dependencies rather than an optional peer changes install semantics for all consumers, including any who only use the runtime ./internal exports and never the build-time transform. Those consumers will now always pull a TypeScript copy. If there is a runtime-only consumption path that never touches the compiler, consider whether typescript could instead be a capped peer (>=5.7.0 <7) so it stays out of pure-runtime installs. If the package is only ever consumed as a build-time transform, the direct dependency is the right call and this is a non-issue.

Nothing blocking from a correctness standpoint. Items 1 and 3 are design confirmations rather than defects.

ask-bonk · 2026-08-12T20:18:03Z

Review posted successfully. Summary of my assessment of PR #240:

Verdict: sound and correctly targeted, no blocking issues.

The change moves typescript from an uncapped peer dependency to a capped direct dependency (>=5.7.0 <7) on capnweb-validate.

What I verified:

The root cause is real — the transform value-imports the TS compiler API (ts.sys, findConfigFile, transpileModule, createProgram) in src/transform/{run,context,transform-module}.ts, which TS 7 (tsgo) doesn't ship.
package.json and package-lock.json are internally consistent (dep added, peer removed, devDep removed, dev: true flag dropped, resolved 5.9.3 satisfies the range).
Root workspace still has typescript: ^5.9.3, so in-repo build/test are unaffected.
Changeset wording matches the actual range.

Points I flagged for the maintainer (design confirmations, not defects):

The <7 cap deliberately forces a duplicate JS-based TS install for TS 7 consumers — intended, but worth noting.
type-introspector.ts uses a type-only import, confirming the runtime need is genuine.
A hard dependencies entry means even runtime-only (./internal) consumers now always pull TypeScript; if such a path exists, a capped peer might be preferable — otherwise the direct dependency is correct.

github run

Maximo-Guk force-pushed the validate-own-compiler branch from 380aa93 to af74f4dCompare August 12, 2026 19:40

Maximo-Guk marked this pull request as ready for review August 12, 2026 19:42

teamchong approved these changes Aug 12, 2026
View reviewed changes

ask-bonkBot reviewed Aug 12, 2026
View reviewed changes

teamchong merged commit f7f7fa8 into cloudflare:mainAug 12, 2026
5 checks passed

github-actionsBot mentioned this pull request Aug 12, 2026
Version Packages #244
Merged

This was referenced Aug 12, 2026
Bump capnweb to 0.11.1 cloudflare/cloudflare-os#175
Merged
Bump typechecking to TypeScript 7.0.2 cloudflare/cloudflare-os#173
Merged

jonastemplestein mentioned this pull request Aug 17, 2026
Rebase fork onto cloudflare/capnweb v0.11.1 iterate/capnweb#6
Merged

Maximo-Guk force-pushed the validate-own-compiler branch from 380aa93 to af74f4dCompare August 12, 2026 19:40

Maximo-Guk marked this pull request as ready for review August 12, 2026 19:42

teamchong approved these changes Aug 12, 2026
View reviewed changes

ask-bonkBot reviewed Aug 12, 2026
View reviewed changes

teamchong merged commit f7f7fa8 into cloudflare:mainAug 12, 2026
5 checks passed

github-actionsBot mentioned this pull request Aug 12, 2026
Version Packages #244
Merged

This was referenced Aug 12, 2026
Bump capnweb to 0.11.1 cloudflare/cloudflare-os#175
Merged
Bump typechecking to TypeScript 7.0.2 cloudflare/cloudflare-os#173
Merged

jonastemplestein mentioned this pull request Aug 17, 2026
Rebase fork onto cloudflare/capnweb v0.11.1 iterate/capnweb#6
Merged

Maximo-Guk force-pushed the validate-own-compiler branch from 380aa93 to af74f4dCompare August 12, 2026 19:40

Maximo-Guk marked this pull request as ready for review August 12, 2026 19:42

teamchong approved these changes Aug 12, 2026
View reviewed changes

ask-bonkBot reviewed Aug 12, 2026
View reviewed changes

teamchong merged commit f7f7fa8 into cloudflare:mainAug 12, 2026
5 checks passed

github-actionsBot mentioned this pull request Aug 12, 2026
Version Packages #244
Merged

This was referenced Aug 12, 2026
Bump capnweb to 0.11.1 cloudflare/cloudflare-os#175
Merged
Bump typechecking to TypeScript 7.0.2 cloudflare/cloudflare-os#173
Merged

jonastemplestein mentioned this pull request Aug 17, 2026
Rebase fork onto cloudflare/capnweb v0.11.1 iterate/capnweb#6
Merged

Maximo-Guk force-pushed the validate-own-compiler branch from 380aa93 to af74f4dCompare August 12, 2026 19:40

Maximo-Guk marked this pull request as ready for review August 12, 2026 19:42

teamchong approved these changes Aug 12, 2026
View reviewed changes

ask-bonkBot reviewed Aug 12, 2026
View reviewed changes

teamchong merged commit f7f7fa8 into cloudflare:mainAug 12, 2026
5 checks passed

github-actionsBot mentioned this pull request Aug 12, 2026
Version Packages #244
Merged

This was referenced Aug 12, 2026
Bump capnweb to 0.11.1 cloudflare/cloudflare-os#175
Merged
Bump typechecking to TypeScript 7.0.2 cloudflare/cloudflare-os#173
Merged

jonastemplestein mentioned this pull request Aug 17, 2026
Rebase fork onto cloudflare/capnweb v0.11.1 iterate/capnweb#6
Merged

Maximo-Guk force-pushed the validate-own-compiler branch from 380aa93 to af74f4dCompare August 12, 2026 19:40

Maximo-Guk marked this pull request as ready for review August 12, 2026 19:42

teamchong approved these changes Aug 12, 2026
View reviewed changes

ask-bonkBot reviewed Aug 12, 2026
View reviewed changes

teamchong merged commit f7f7fa8 into cloudflare:mainAug 12, 2026
5 checks passed

github-actionsBot mentioned this pull request Aug 12, 2026
Version Packages #244
Merged

This was referenced Aug 12, 2026
Bump capnweb to 0.11.1 cloudflare/cloudflare-os#175
Merged
Bump typechecking to TypeScript 7.0.2 cloudflare/cloudflare-os#173
Merged

jonastemplestein mentioned this pull request Aug 17, 2026
Rebase fork onto cloudflare/capnweb v0.11.1 iterate/capnweb#6
Merged

Maximo-Guk force-pushed the validate-own-compiler branch from 380aa93 to af74f4dCompare August 12, 2026 19:40

Maximo-Guk marked this pull request as ready for review August 12, 2026 19:42

teamchong approved these changes Aug 12, 2026
View reviewed changes

ask-bonkBot reviewed Aug 12, 2026
View reviewed changes

teamchong merged commit f7f7fa8 into cloudflare:mainAug 12, 2026
5 checks passed

github-actionsBot mentioned this pull request Aug 12, 2026
Version Packages #244
Merged

This was referenced Aug 12, 2026
Bump capnweb to 0.11.1 cloudflare/cloudflare-os#175
Merged
Bump typechecking to TypeScript 7.0.2 cloudflare/cloudflare-os#173
Merged

jonastemplestein mentioned this pull request Aug 17, 2026
Rebase fork onto cloudflare/capnweb v0.11.1 iterate/capnweb#6
Merged

Maximo-Guk force-pushed the validate-own-compiler branch from 380aa93 to af74f4dCompare August 12, 2026 19:40

Maximo-Guk marked this pull request as ready for review August 12, 2026 19:42

teamchong approved these changes Aug 12, 2026
View reviewed changes

ask-bonkBot reviewed Aug 12, 2026
View reviewed changes

teamchong merged commit f7f7fa8 into cloudflare:mainAug 12, 2026
5 checks passed

github-actionsBot mentioned this pull request Aug 12, 2026
Version Packages #244
Merged

This was referenced Aug 12, 2026
Bump capnweb to 0.11.1 cloudflare/cloudflare-os#175
Merged
Bump typechecking to TypeScript 7.0.2 cloudflare/cloudflare-os#173
Merged

jonastemplestein mentioned this pull request Aug 17, 2026
Rebase fork onto cloudflare/capnweb v0.11.1 iterate/capnweb#6
Merged

Maximo-Guk force-pushed the validate-own-compiler branch from 380aa93 to af74f4dCompare August 12, 2026 19:40

Maximo-Guk marked this pull request as ready for review August 12, 2026 19:42

teamchong approved these changes Aug 12, 2026
View reviewed changes

ask-bonkBot reviewed Aug 12, 2026
View reviewed changes

teamchong merged commit f7f7fa8 into cloudflare:mainAug 12, 2026
5 checks passed

github-actionsBot mentioned this pull request Aug 12, 2026
Version Packages #244
Merged

This was referenced Aug 12, 2026
Bump capnweb to 0.11.1 cloudflare/cloudflare-os#175
Merged
Bump typechecking to TypeScript 7.0.2 cloudflare/cloudflare-os#173
Merged

jonastemplestein mentioned this pull request Aug 17, 2026
Rebase fork onto cloudflare/capnweb v0.11.1 iterate/capnweb#6
Merged

Uh oh!

Conversation

Maximo-Guk commented Aug 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

changeset-botBot commented Aug 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

pkg-pr-newBot commented Aug 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

teamchong commented Aug 12, 2026

Uh oh!

ask-bonkBot left a comment

Choose a reason for hiding this comment

Review: ship typescript as a capped dependency

Consistency check (all good)

Points worth confirming before merge

Uh oh!

ask-bonkBot commented Aug 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Maximo-Guk commented Aug 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

changeset-botBot commented Aug 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

pkg-pr-newBot commented Aug 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

teamchong commented Aug 12, 2026

Uh oh!

ask-bonkBot left a comment

Choose a reason for hiding this comment

Review: ship typescript as a capped dependency

Consistency check (all good)

Points worth confirming before merge

Uh oh!

ask-bonkBot commented Aug 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Maximo-Guk commented Aug 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

changeset-botBot commented Aug 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

pkg-pr-newBot commented Aug 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

teamchong commented Aug 12, 2026

Uh oh!

ask-bonkBot left a comment

Choose a reason for hiding this comment

Review: ship typescript as a capped dependency

Consistency check (all good)

Maximo-Guk commented Aug 12, 2026•
edited
Loading

changeset-botBot commented Aug 12, 2026•
edited
Loading

pkg-pr-newBot commented Aug 12, 2026•
edited
Loading

Maximo-Guk commented Aug 12, 2026•
edited
Loading

changeset-botBot commented Aug 12, 2026•
edited
Loading

pkg-pr-newBot commented Aug 12, 2026•
edited
Loading

Maximo-Guk commented Aug 12, 2026•
edited
Loading

changeset-botBot commented Aug 12, 2026•
edited
Loading

pkg-pr-newBot commented Aug 12, 2026•
edited
Loading

Maximo-Guk commented Aug 12, 2026•
edited
Loading

changeset-botBot commented Aug 12, 2026•
edited
Loading

pkg-pr-newBot commented Aug 12, 2026•
edited
Loading

Maximo-Guk commented Aug 12, 2026•
edited
Loading