-
Notifications
You must be signed in to change notification settings - Fork 2.8k
update VS Code built-in extensions to 1.104.0 and Typescript to 5.9.3 #16774
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
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
pisv
left a comment
There was a problem hiding this 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:
but are not present there now:
(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) { |
There was a problem hiding this comment.
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.
|
Thanks @pisv for testing and reviewing, much appreciated! 🎉 |
What it does
update VS Code built-in extensions and plugin downloaderchore: upgrade typescript to ~5.9.3fix: disable ES2022 class field semantics useDefineForClassFields=falsefix: update code for new typescript versionvscode: implement proposed.editorHoverVerbosityLevel APIResolves 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
npm run clean && git clean -xdf)npm run allnpm run download:pluginsFollow-ups
vscode.githubandvscode.github-authentication(see also Authentication provider registration of VSCode based extensions not working #16713)useDefineForClassFields=falsetopicBreaking changes
Attribution
Contributed on behalf of STMicroelectronics
Review checklist
nlsservice (for details, please see the Internationalization/Localization section in the Coding Guidelines)Reminder for reviewers