ReviewOS

stacks/stx

Published dist/composables.d.ts is syntactically invalid, and a syntax error in a .d.ts is not skipLibCheck-able

#1888
Closed glennmichael123 opened this 14 days ago · 0 comments
14 days ago

Summary

packages/stx/dist/composables.d.ts is syntactically invalid. dist/ is in the package's published files, so this ships. Any consumer whose program pulls the file in gets parse errors, and a syntax error in a declaration file is not suppressible with skipLibCheck — that only silences semantic diagnostics.

The broken output

dist/composables.d.ts:227-233:

export declare const RouterKey: (createInjectionKey<{
  currentRoute: string
  navigate: (path: string)) => unknown;
/** Built-in injection key for i18n */
export declare const I18nKey: (createInjectionKey<{
  locale: string
  t: (key: string)) => unknown;

Both are truncated mid-signature: the parameter list of navigate / t is cut off and then closed with the outer paren, so the declaration ends (path: string)) => unknown;. There are 2 occurrences in the file.

tsc --pretty false on a program including it:

packages/stx/dist/composables.d.ts(229,27): error TS1005: '=>' expected.
packages/stx/dist/composables.d.ts(229,29): error TS1005: ';' expected.
packages/stx/dist/composables.d.ts(233,19): error TS1005: '=>' expected.
packages/stx/dist/composables.d.ts(233,21): error TS1005: ';' expected.

Why it matters beyond the noise

tsc stops on this. Building the stx typecheck command (#1852) I included the package's own stx.d.ts so runtime globals would resolve; that pulled these declarations in, tsc aborted on the syntax errors, and the checker reported zero diagnostics about the user's actual code while exiting as though the run had succeeded. The failure looks like "no type errors", which is the worst possible shape for a checking tool.

I worked around it there by generating the global declarations instead of including stx.d.ts, but any consumer that ends up with this file in their program has no such workaround.

Likely cause

This looks like a .d.ts generator bug rather than a hand-edit: both failures are the same shape (a nested function-typed property inside a generic type argument), and the surrounding declarations are fine. Worth checking whether dtsx mishandles a function type nested inside a type argument to a generic call.

Ask

  1. Regenerate dist/ and confirm the two declarations round-trip.
  2. Add a build-time check that the emitted .d.ts files parse — a syntax error in published types should fail the release, not reach consumers.

Sign in to comment on this issue.