Skip to content

Conversation

@ndoschek
Copy link
Member

@ndoschek ndoschek commented Dec 18, 2025

What it does

  • update VS Code built-in extensions and plugin downloader
    • Resolves [vscode] update VS Code built-in extensions #16279
    • update built-in extensions to version 1.104.0 and consume tar.gz archive from GitHub releases instead of open-vsx for now
    • add support for decompressing vsix bundles from tar.gz archives
    • ensure download:plugins command exits with proper exit codes
    • update theiaPlugins versions (EditorConfig, ESLint, Jupyter)
    • remove vscode.microsoft-authentication from excluded IDs (as it is not a standalone built-ins anymore)
    • remove ms-vscode.references-view from excluded IDs (it is now vscode.references.view and works without issues)
  • chore: upgrade typescript to ~5.9.3
  • fix: disable ES2022 class field semantics useDefineForClassFields=false
    • TypeScript 5+ with target ES2022+ changes how class fields are initialized by using Object.defineProperty semantics that can alter initialization order relative to super() calls. Several parts of our codebase rely on the older (ES2019-style) behavior where field assignments occur after the super() call, so this flag preserves compatibility for now. We can revisit this later and enable the standard behavior (useDefineForClassFields=true) once all affected classes are refactored to be spec-compliant.
  • fix: update code for new typescript version
    • Three main areas of updates:
      • for overridden injects/members, use declare instead of override
      • v regex flag is only available when targeting 'esnext' or later (we still use commonjs)
      • do not use properties before their initialization
  • vscode: implement proposed.editorHoverVerbosityLevel API

Resolves GH-16279
Resolves GH-16400
Resolves GH-16397
Fixes GH-16753

More details about the switch to an archive instead of the extension pack:

Open VSX changed its ownership behavior, and now you need to claim a namespace to be able to publish an extension under it.
Our extension pack was already in the eclipse-theia namespace, but all the bundled extensions were under the vscode namespace. Unsurprisingly, the vscode namespace is claimed by Microsoft.
Previously, this wasn’t an issue, and we were still able to publish the extensions under the vscode namespace.
Also, the extension pack is an Open VSX concept.
As an intermediate solution, we discussed in the last dev meeting that we’ll temporarily skip the Open VSX publishing step, package the VSIX ourselves, and consume it with less effort for now, since the last built-in update was over a year ago.
We decided to postpone the final decision on whether we want to continue publishing on Open VSX and how to resolve the namespace problem.
We also considered changing the publisher to eclipse-theia, but this might lead to unforeseen issues.
For example, if other extensions depend on the built-ins, we might need some kind of hacky workaround to intercept and override the publisher prefix somewhere in Theia.
And since they were always intended to be "built-in", there's probably not too much benefit in having them listed in the store.

How to test

  • start with a clean repo (ideally run: npm run clean && git clean -xdf)
  • npm run all
  • npm run download:plugins
  • Test built-in extensions with browser and electron example applications:
    • Typescript language support
    • other language support (like json, css etc)
    • git support (scm view, but not support all features fully yet, see also follow ups)
    • Observe logs for new exceptions/errors/warnings

Follow-ups

Breaking changes

  • This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Contributed on behalf of STMicroelectronics

Review checklist

Reminder for reviewers

Resolves GH-16279

- update built-in extensions to version 1.104.0 and consume tar.gz archive from GitHub releases instead of open-vsx for now
- add support for decompressing vsix bundles from tar.gz archives
- ensure download:plugins command exits with proper exit codes
- update theiaPlugins versions (EditorConfig, ESLint, Jupyter)
- remove vscode.microsoft-authentication from excluded IDs (as it is not a standalone built-ins anymore)
- remove ms-vscode.references-view from excluded IDs (it is now vscode.references.view and works without issues)

Contributed on behalf of STMicroelectronics
- update base tsconfig target to ES2023 as we support >= Node 20

Resolves GH-16400

Contributed on behalf of STMicroelectronics
TypeScript 5+ with target ES2022+ changes how class fields are initialized by using Object.defineProperty semantics that can alter initialization order relative to super() calls.
Several parts of our codebase rely on the older (ES2019-style) behavior where field assignments occur after the super() call, so this flag preserves compatibility for now.

We can revisit this later and enable the standard behavior (useDefineForClassFields=true) once all affected classes are refactored to be spec-compliant.

Contributed on behalf of STMicroelectronics
Three main areas of updates:
- for overridden injects/members, use declare instead of override
- v regex flag is only available when targeting 'esnext' or later (we still use commonjs)
- do not use properties before their initialization

Contributed on behalf of STMicroelectronics
Resolves GH-16397

- add proposed API definitions for editorHoverVerbosityLevel to support verbose hover (e.g. for typescript uses this in most cases now)
- update plugin HoverAdapter that provides/releases hover
- Remark: increase/decrease level will most likely work then with updated monaco version (GH-16401)

Contributed on behalf of STMicroelectronics
Copy link
Contributor

@pisv pisv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ndoschek Thank you very much for all this effort! 👍

I can confirm that #16753 is fixed by this PR 🎉

I also tested git support to some extent and found a regression in the code editor's dirty diff peek view, where the actions for staging/reverting the current change were previously visible in the peek view's action bar like this:

Screenshot

but are not present there now:

Screenshot

(It is explicitly mentioned in the PR description regarding git support that all features might currently not be available, so a follow-up PR could probably fix this regression.)

toDispose.push(button.onClick(() =>
this.withContext(context, () => firstMatch.run(EDITOR_CONTENT_MENU, editorWidget))
));
if (menuNodes) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nitpick] Although this additional check will certainly not hurt anything, it does not look like it's really necessary, as menuNodes is CommandMenu[] and cannot be falsy here.

@ndoschek
Copy link
Member Author

Thanks @pisv for testing and reviewing, much appreciated! 🎉
I'll take another look after the holiday break!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Waiting on reviewers

3 participants