Bundled Svelte 4 types loaded in a Svelte 5 project and causing conflict
Describe the bug
See title and repro
Work around is to add the types to the callbacks manually but that skips typechecking so not ideal.
Reproduction
import { writable, type Writable } from 'svelte/store';
...
let _curMessage: string;
const currentMessage = writable<string>('');
currentMessage.subscribe((cur) => (_curMessage = cur));
node_modules/svelte/src/store/shared/index.js:
Logs
n/a vscode
System Info
osx apple m1 Sonoma
VSCode
Version: 1.90.1 (Universal)
Commit: 611f9bfce64f25108829dd295f54a6894e87339d
Date: 2024-06-11T21:02:41.372Z
Electron: 29.4.0
ElectronBuildId: 9593362
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Darwin arm64 22.1.0
Severity
annoyance
Strictly speaking, I don't know whether this is because of svelte or vscode or typescript. I just know it's a new problem after upgrading svelte
This seems to be caused by the Svelte for VSCode extension. It seems to be because of the conflict between the Svelte 4 type definition bundled by the Svelte extension and the workspace Svelte 5 types. Interestingly the type no longer conflicts in TypeScript 5.5+ but not because of the support for the JSDoc template tag. The actual type loaded is still the hidden .d.ts file. What you see in go to definition is because of the declaration map. The reason is probably because TypeScript 5.5 got slightly smarter at choosing between overloads with very similar types.
@jasonlyu123 do you have an idea why our bundled types are loaded? Is it because of our d.ts files in svelte2tsx which reference Svelte imports? I always had the impression that those are pointing back to the user's Svelte version.
It's like require.resolve('svelte', '/path/to/shims.d.ts') I think. Not sure if we can move the import to the generated code and pass it into the helper function as a parameter. Or if we could create a virtual module inside the user's node_modules to re-export from svelte.