Skip to content

Frontend: update/upgrade PNPM packages - #1373

Merged
gusthoff merged 9 commits into
AdaCore:mainfrom
gusthoff:dev/topic/infrastructure/pnpm/upgrade-deps/2026-07-24
Jul 24, 2026
Merged

Frontend: update/upgrade PNPM packages#1373
gusthoff merged 9 commits into
AdaCore:mainfrom
gusthoff:dev/topic/infrastructure/pnpm/upgrade-deps/2026-07-24

Conversation

@gusthoff

Copy link
Copy Markdown
Collaborator

No description provided.

gusthoff and others added 7 commits July 24, 2026 14:27
typescript@7.0.2 restructured the package's exports map so that a plain
`require('typescript')` no longer resolves to the classic compiler API.
It now points at `lib/version.cjs`, a stub exposing only `version` and
`versionMajorMinor` - `ts.sys` and the rest of the compiler surface are
gone from the default export, moved under new `./unstable/*` subpaths.

ts-node@10.9.2 (and anything else that does `require('typescript')`
expecting the classic API) breaks immediately as a result:

  TypeError: Cannot read properties of undefined (reading 'fileExists')
    at readConfig (.../ts-node/dist/configuration.js:91:33)

This crashed `pnpm run cover` (and therefore `make site-testing &&
pnpm run cover`) before a single test file could even be parsed.

ts-node has not seen a real release since 10.9.2 in December 2023, so
there is no version of it that could support the new layout. Checked
the registry directly: typescript@6.0.3 (the last release before the
7.0.x restructuring) has no `exports` field at all and behaves like
5.9.3 for tooling purposes, so it is a genuine, working upgrade over
the previous ^5.9.3 pin without the breakage.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
tsconfig.json's "lib" has been ["es2023"] with no "dom" since
2024-11-02 (commit f1c7385), so identifiers like `document`,
`HTMLElement`, and `HTMLDivElement` had no ambient declarations
available to the TypeScript compiler.

This was invisible until now because ts-node was crashing at an
earlier bootstrap stage (fixed in the previous commit) before it
ever got far enough to type-check a test file and hit these names.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
With "types" left unset, TypeScript's default auto-inclusion of
@types packages was not picking up @types/mocha's ambient globals in
this project's ts-node + ESM-loader + "moduleResolution": "bundler"
setup, even though @types/mocha is correctly installed and resolvable
at node_modules/@types/mocha. `describe`, `it`, `before`, `after`,
etc. all failed to resolve with "Cannot find name" once ts-node
reached the point of type-checking a test file.

Adding an explicit "types": ["mocha"] resolves it.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Adding "dom" to tsconfig's "lib" (previous-but-one commit) made the
global `WebSocket` identifier resolve to the DOM lib's stricter type,
whose `readyState` is the literal union 0 | 1 | 2 | 3. mock-socket's
own WebSocket class types `readyState` as a plain `number`, so the
`global.WebSocket = WebSocket` assignment in these two test files no
longer type-checked:

  error TS2322: Type 'typeof WebSocket' is not assignable to type
  '{ new (url: string | URL, ...): WebSocket; ... }'.
    The types of 'prototype.readyState' are incompatible between
    these types.
      Type 'number' is not assignable to type '0 | 1 | 2 | 3'.

Cast the assignment to globalThis.WebSocket's type in both files to
resolve it.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
@types/jszip is a deprecated stub types package: jszip has shipped its
own type definitions (types: "./index.d.ts" in its package.json) for a
while now, so the separate @types package is unnecessary and flagged
as deprecated by the registry.

Confirmed jszip is still actively used (src/ts/download.ts,
tests/ts/download.spec.ts import it directly) and that removing the
stub does not affect type-checking or the test suite (126 passing,
100% statement coverage unchanged).

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
gusthoff and others added 2 commits July 24, 2026 16:13
CI failed on `pnpm run production` (the ts-loader/webpack build,
which the mocha-based test suite does not exercise) with:

  TS5101: Option 'downlevelIteration' is deprecated and will stop
  functioning in TypeScript 7.0. Specify compilerOption
  '"ignoreDeprecations": "6.0"' to silence this error.

typescript@6.0.3 (pinned in an earlier commit on this branch) now
treats use of this deprecated option as a hard error rather than a
warning.

`downlevelIteration` only has any effect when down-leveling for-of
and spread over iterables to a pre-ES2015 target. Per `git blame`,
this flag dates back to 2020-10-02, from before "target" was raised
to "es2022" on 2024-11-02 (commit f1c7385) - it has been dead,
no-op configuration for over a year. Removing it (rather than
silencing the deprecation with "ignoreDeprecations") is the correct
fix, not a workaround.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
CI failed on `pnpm run production` alongside the downlevelIteration
error, in the same ts-loader/webpack build:

  TS2882: Cannot find module or type declarations for side-effect
  import of './styles/learn.scss'.

typescript@6.0.3 added stricter resolution checking for side-effect-
only imports (`import './styles/learn.scss';` in src/index.ts, with
no bound identifier). There was no ambient module declaration
anywhere in this codebase for non-TS asset types like .scss - it is
a resource webpack's sass-loader/css-loader handle, not something
TypeScript itself can resolve as a module.

Added the standard `declare module '*.scss';` ambient declaration in
a new src/global.d.ts, picked up automatically via tsconfig.json's
"include": ["./src/**/*"].

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
@gusthoff
gusthoff merged commit 531b672 into AdaCore:main Jul 24, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant