Upgrade to TypeScript 6.0 - #219
Conversation
…solution to node10 and module to commonjs (needs to be resolved before upgrading to TS 7.0)
|
@yoavbls Can you take a look at this and try build locally. Its main effort is to update to TS 6.0, which should make the migration to 7.0 easier. |
yoavbls
left a comment
There was a problem hiding this comment.
Thank you Kevin! Looks good to me.
I test it locally and it builds properly
We're not using the typescript sdk so technically we can upgrade to 7.0 after it 🙂
I setup a draft PR at #222, while we don't use the SDK, our tooling does, so there is not much to be gained yet. I will update the draft once 7.1 releases. |
This PR will update TypeScript and its related dependencies towards
6.x.x. TS 6 is a intermediate step towards version 7, which has been released.For more info about version 6 and 7, see the related typescript blogs.
It also tightens some security settings with npm packages.
NOTE: This PR upgrades the repo to use typescript 6.0 as part of its build process, it does not contain any changes or tests to check if the extension works properly with 6.0 (or 7.0).
Related docs/links:
typescript-eslint@8.58.xsupports TS 6.0Changes:
typescriptto^6.0.3typescrit-eslintto^8.63.0compilerOptionsintsconfig.base.json(to make it easier to use the 6.0 and 7.0 migration guides)baseUrl, as its deprecatedlibReplacement, as its new default will befalsemoduletopreserve, ascommonjsis now deprecated. this seems to be the recommended setting when "my code & bundler works, dont bother me" (see Allow--module commonjs --moduleResolution bundlermicrosoft/TypeScript#62320)moduleResolutiontobundler, asnodeis now deprecated. same asmodule.noUncheckedIndexedAccess, as its new default will betruetypeswith["node"], as its new default will be an empty array, causing build errors.referencesto be an explicit relative path, related to new defaults ofbaseUrlandrootPath. I think it would work fine without, but the migration guide recommends explicit paths.dedentfrom a default import (import dedent from 'ts-dedent') to a named import (import { dedent } from 'ts-dedent'). I checked the source and it exports it both as named and the default, but the new module resolution settings broke the lint task and IDE (build still worked though, no idea why). Named imports still are a better fit as its proper ESM syntax, so its probably a good reason why it errored.Additional changes:
@vscode/vscea local dependency instead of a global install (docs and repo). By making this an explicit local dependency, we can ensure its version and thus anyallowScriptspermission it requires.esbuild@0.28.1toallowScripts@vscode/vsce-sign@2.0.9toallowScriptskeytar@7.9toallowScriptsThese additional changes are related to
allowScripts(see https://docs.npmjs.com/cli/v11/commands/npm-approve-scripts).With the recent security fiascos (also mentioned in #217), I figure these are good changes on the end of npm. It might be because I updated my node version to the latest LTS, that these are now required by default.
Since this extension has quite some users and developers (and their code) have been target of these attacks, it would be good practice to ensure our extension repo is as secure as our tools allow it to be.
I checked these install scripts myself to ensure there are no malicious or hidden effects, and pinned them to their versions to decrease the chance of a supply chain attack.