App: Cursor
OS: macOS (darwin 24.6.0)
Workspace package: [email protected] (installed under node_modules/typescript)
Workspace setting: “typescript.tsdk”: “node_modules/typescript/lib”
UI: Select TypeScript Version
What happens
Cursor’s built-in TypeScript for JS/TS language features is still 6.0.3 (“Use VS Code’s Version 6.0.3”).
Choosing “Use Workspace Version” fails with:
Unable to get TypeScript version for this directory node_modules/typescript/lib
The workspace does have a valid install: require(‘typescript/package.json’).version === “7.0.2”.
Why this likely fails TypeScript 7.0.2 no longer ships the classic VS Code/tsserver layout under lib/. In this install, node_modules/typescript/lib only contains:
tsc.js
version.cjs / version.d.cts
getExePath.js / getExePath.d.ts
There is no typescript.js / tsserver.js (or equivalent) at the path Cursor historically probes. Version resolution that assumes the TS 5.x/6.x lib/ layout will fail even when the package is correctly installed.
Requests / suggestions
Upgrade Cursor’s bundled TypeScript to 7.0.2 (or the latest stable 7.x) so language features match current projects.
Fix workspace TypeScript detection for TS 7.x:
Read version from node_modules/typescript/package.json or lib/version.cjs (versionMajorMinor: “7.0”).
Support the new package exports / entrypoints instead of requiring the old lib/tsserver.js layout.
Surface a clearer error when the SDK path exists but is incompatible (e.g. “TypeScript 7 package layout not supported yet”) rather than “unable to get version”.
Expected
Workspace TypeScript 7.0.2 is selectable and used for language features, or
Cursor clearly states TS 7 is not supported yet, with a timeline / tracking issue.
Actual
Stuck on bundled 6.0.3
Workspace 7.0.2 cannot be selected
Steps to Reproduce
npm i -D [email protected]
Set “typescript.tsdk”: “node_modules/typescript/lib”
Command Palette → “TypeScript: Select TypeScript Version”
Observe: bundled 6.0.3 works; workspace version fails to resolve
Hey, thanks for the detailed report. Your breakdown is spot on. The key point is that TypeScript 7 native (the tsgo port) intentionally does not ship the classic lib/tsserver.js. The “Select TypeScript Version” flow and typescript.tsdk rely on tsserver.js being present, so a TS7 native install can’t be resolved and it fails with “Unable to get TypeScript version”. This is upstream VS Code behavior, not a Cursor specific break. So seeing bundled 6.0.3 for classic language features is expected.
The right way to enable TS7 native is not via typescript.tsdk, but like this:
Install the extension “TypeScript Native Preview” (in the marketplace it may show up as “TypeScript 7”, TypeScriptTeam.native-preview). If it doesn’t appear in the Extensions panel, you can install it via VSIX. Instructions are in this thread: TSGO is needed, extension not available in cursor
Enable the setting js/ts.experimental.useTsgo: true (this is the current name. In older versions it was typescript.experimental.useTsgo). Or use the Command Palette: TypeScript Native Preview: Enable Experimental.
After that, the same version picker will show a separate option for tsgo. You can’t select TS7 native via the tsdk path since there is no JS tsserver.js and the classic mechanism depends on it.
A couple honest caveats. tsgo is still experimental, and some things behave differently, like Restart TS Server and Show Output not working the same way as with the classic server. There used to be an issue where turning this setting on would prevent the TS server from starting at all, but that was fixed in v3.10.11. You’re on 3.11.6, so you have the fix. If IntelliSense still acts weird after enabling it, just remove the setting to go back to classic tsserver and let me know.
Also agreed that the error message could be clearer. “Unable to get version” for a valid but incompatible layout is confusing, I’ll flag that.
That’s no longer the case. TS 7 was released 5 days ago (RC ~3 weeks before) and MS seems confident: “Visual Studio will automatically enable TypeScript 7 based on your workspace”, “Battle-Tested and Ready for Production”
For feature parity and convenience, it seems to me like a move Cursor should make as well, if possible.
Using Go programming, it is said that the performance has improved by nearly 10 times. If our cursor’s TSServer is upgraded to TypeScript 7, the overall performance of cursor in TypeScript projects will be much better than before
Thanks for the details and screenshots. I can see both tsserver 6.0.3 memory usage, and that your local tsc is already 7.0.2. The performance point makes sense, tsgo really is faster and uses less memory.
Status wise, nothing has changed from what I wrote above. TS7 native tsgo intentionally does not ship the classic lib/tsserver.js, so it can’t be picked up via Select TypeScript Version or typescript.tsdk. That is a limitation of the classic mechanism inherited from VS Code, not a Cursor specific bug. That is why language features still show bundled 6.0.3 for now.
The working way to run tsgo right now is still the same:
Enable js/ts.experimental.useTsgo: true or use Command Palette → TypeScript Native Preview: Enable Experimental.
Once enabled, IntelliSense will switch to tsgo. You might not see a separate entry in the version picker, and that is normal. There is no functional difference, just judge it by how the language features behave.
@icookandcode: in VS Code this “just works” because of how Microsoft integrated Native Preview. In Cursor, for now you need the extension plus the setting as a workaround. There is no out of the box switch without the extension yet.
I’ll pass the request to bundle TS7 by default and allow switching without an extra extension to the team. I can’t promise a timeline, but I’ll update the thread when we have something concrete.
@deanrie is there any update on this? Cursor is the only single IDE on the market that doesn’t properly support TypeScript 7. Even with the mentioned extension, it doesn’t pick up the correct TypeScript version from the codebase, suggesting only the built-in one 0.20260722.1.
@ivoronin1 No status update yet, it’s the same situation I described above. I passed your request to bundle TS7 native by default and add a switch without a separate extension to the team, but I can’t share a specific timeline. I’ll post here as soon as I have anything to share.
About the extension only pulling 0.20260722.1, that’s not a separate issue. It’s the current behavior of the Native Preview extension itself. It uses its built-in tsgo (0.20260722.1 is the extension’s date-based version, not a TypeScript version), not [email protected] from your workspace. Picking the workspace version via typescript.tsdk or Select TypeScript Version doesn’t work for TS7 native because this layout doesn’t have the classic lib/tsserver.js that this mechanism depends on. This is inherited from VS Code, not something Cursor-specific. Don’t rely on the version picker entry. Instead, look at how the language features behave after enabling js/ts.experimental.useTsgo: true.
If IntelliSense behaves incorrectly after you enable it, let me know and we’ll dig in.
The problem is that it uses the built-in version in the extension (so 0.20260722.1), while I expect the one installed in the workspace (7.0.2). VSCode detects the needed version automatically if the extension is in place, so I’d expect the same behaviour in Cursor.
@ivoronin1, got it. Let me break down why this happens.
0.20260722.1 is the version of the TypeScript Native Preview extension itself. It is a date-based build that includes its own bundled tsgo. It is not the TypeScript version. By default, the extension runs its bundled tsgo, not [email protected] from your workspace, so that is the number you see in the picker.
To point the extension to a specific tsgo install, Native Preview has its own separate setting. It is not the classic typescript.tsdk, it is typescript.native-preview.tsdk. Important detail: it has to point not to the package root, but to the platform-specific lib directory that contains the binary. @typescript/native-preview is a wrapper that resolves a platform peer package like @typescript/native-preview-darwin-arm64, so the path looks like this:
Swap in your platform and arch like darwin-arm64, linux-x64, etc. The classic typescript.tsdk and Select TypeScript Version still won’t work here, because TS7-native does not have lib/tsserver.js, which the old mechanism depends on.
I already passed along your request to bundle TS7 by default and allow switching without a separate extension. Status is unchanged for now, so I can’t share a timeline yet. I’ll update here as soon as I have news.
Try setting typescript.native-preview.tsdk to the platform-specific lib path and tell me if it picks up the right install.
