Description

TypeScript updates a minor version every quarter.

Description

https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/

https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/#what’s-next

As you might have heard, much of our recent focus has been on the native port of TypeScript which will eventually be available as TypeScript 7.0. So what does that mean for TypeScript 6.0?

Our vision for TypeScript 6.0 is to act as a transition point for developers to adjust their codebases for TypeScript 7.0. While TypeScript 6.0 may still ship updates and features, most users should think of it as a readiness check for adopting TypeScript 7.0. This new version is meant to align with TypeScript 7.0, introducing deprecations around certain settings and possibly updating type-checking behavior in small ways. Luckily, we don’t predict most projects will have too much trouble upgrading to TypeScript 6.0, and it will likely be entirely API compatible with TypeScript 5.9.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/#support-for-import-defer

TypeScript 5.9 introduces support for ECMAScript’s deferred module evaluation proposal using the new import defer syntax. This feature allows you to import a module without immediately executing the module and its dependencies, providing better control over when work and side-effects occur.

The syntax only permits namespace imports.

Which we will soon report as errors, except from yup package.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/#support-for---module-node20

TypeScript provides several node* options for the --module and --moduleResolution settings. Most recently, --module nodenext has supported the ability to require() ECMAScript modules from CommonJS modules, and correctly rejects import assertions (in favor of the standards-bound import attributes).

TypeScript 5.9 brings a stable option for these settings called node20, intended to model the behavior of Node.js v20. This option is unlikely to have new behaviors in the future. Also specifying --module node20 will imply --target es2023 unless otherwise configured.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/#summary-descriptions-in-dom-apis

Previously, many of the DOM APIs in TypeScript only linked to the MDN documentation for the API. These links were useful, but they didn’t provide a quick summary of what the API does. TypeScript now includes summary descriptions for many DOM APIs based on the MDN documentation.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/#expandable-hovers-(preview)

Quick Info (also called “editor tooltips” and “hovers”) can be very useful for peeking at variables to see their types, or at type aliases to see what they actually refer to. Still, it’s common for people to want to go deeper and get details from whatever’s displayed within the quick info tooltip.

TypeScript 5.9 is now previewing a feature called expandable hovers, or “quick info verbosity”. If you use an editor like VS Code, you’ll now see a + and - button on the left of these hover tooltips. Clicking on the + button will expand out types more deeply, while clicking on the - button will collapse to the last view.

we are seeking feedback for both TypeScript and our partners on Visual Studio Code.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/#configurable-maximum-hover-length

Occasionally, quick info tooltips can become so long that TypeScript will truncate them to make them more readable. The downside here is that often the most important information will be omitted from the hover tooltip, which can be frustrating. To help with this, TypeScript 5.9’s language server supports a configurable hover length, which can be configured in VS Code via the js/ts.hover.maximumLength setting.

Additionally, the new default hover length is substantially larger than the previous default. This means that in TypeScript 5.9, you should see more information in your hover tooltips by default.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/#lib.d.ts-changes

Types generated for the DOM may have an impact on type-checking your codebase.

Additionally, one notable change is that ArrayBuffer has been changed in such a way that it is no longer a supertype of several different TypedArray types. This also includes subtypes of UInt8Array, such as Buffer from Node.js.

Procedure

1. Update babel packages, especially preset-typescript package.
   If TypeScript adds new syntax, wait until babel packages update to support it.
   By the way, babel eslint-parser might be because of react-scripts, but unused.
   Also I skipped update to plugin-proposal-private-property-in-object because of react-scripts if I remember correctly.

2. Update core-js package in dependencies object.

3. Update typescript-eslint packages. It supports TypeScript 5.9 in 8.39.0 on 2025-08-43 just a few days after 2025-08-01.
   Before, update npm run lint displays the following:

   • @typescript-eslint/typescript-estree version: 8.35.0
   • Supported TypeScript versions: >=4.8.4 <5.9.0
   • Your TypeScript version: 5.9.2

One-time changes

1. Move "@babel/runtime" from devDependencies to dependencies according to:

   https://babeljs.io/docs/babel-plugin-transform-runtime

   Install it as development dependency.
   and @babel/runtime as a production dependency (since it's for the "runtime").

   https://babeljs.io/docs/babel-runtime

   npm install --save @babel/runtime

   Similarly "@openshift-console/dynamic-plugin-sdk" from devDependencies to dependencies in ROX-29844: Add configuration of base URL in plugin requests #16097

   It appears that the corresponding move in package-lock.json file did not occur in that contribution, therefore commit it now.

   Ditto for change to package-lock.json file that from change to package.json file in ROX-30343: Update Node.js requirement for ui folder to 20.0.0 #16186
   https://github.com/stackrox/stackrox/compare/ROX-30446-devDependencies-typescript-5.9.2?expand=1#diff-4050b8f7b12d0dbca14cee115ca80ab9df71dabdd1394273f67cf0506e3753a7L162-R158

2. Delete obsolete "@babel/eslint-parser" according to:

   https://www.npmjs.com/package/@babel/eslint-parser

   @babel/eslint-parser is a parser that allows ESLint to run on source code that is transformed by Babel

   Passive voice is ambiguous: allows ESLint to run on input to or output from Babel?

   You only need to use @babel/eslint-parser if you are using Babel to transform your code. If this is not the case, please use the relevant parser for your chosen flavor of ECMAScript (note that the default parser supports all non-experimental syntax as well as JSX).

   We are using Babel to transform the JavaScript code that TypeScript outputs.

   In any case, our ESLint configurstion uses @typescript-eslint/parser

3. Delete 3 obsolete babel packages that, at best, were left over from create-react-app

   • "@babel/plugin-proposal-decorators"
   • "@babel/plugin-proposal-private-property-in-object"
   • "@babel/plugin-transform-flow-strip-types"

Observation

Thankfully, babel packages replace their dependency on globals with "@babel/helper-globals" therefore ends wresting match between version for compile and lint.

User-facing documentation

• CHANGELOG.md update is not needed
• documentation PR is not needed

Testing and quality

• the change is production ready: the change is GA, or otherwise the functionality is gated by a feature flag
• CI results are inspected

Automated testing

• added unit tests
• added e2e tests
• added regression tests
• added compatibility tests
• modified existing tests

How I validated my change

For contribution npm install to update package-lock.json file according to changes in package.json file, but for team npm ci to delete and recreate node_modules folder.

1. npm run tsc in ui/apps/platform
2. npm run lint in ui/apps/platform
3. npm run build in ui/apps/platform
4. npm run start in ui/apps/platform