Debug Failure. Unhandled Diagnostic: 2626 #42773
Comments
|
@armanio123 looks like we're straightforwardly missing a case in |
|
I'm hitting this as well with {
"compilerOptions": {
"baseUrl": "./",
"jsx": "preserve",
"noEmit": true,
"module": "esnext",
"esModuleInterop": true,
"strict": true,
"alwaysStrict": true,
"noImplicitThis": false,
"resolveJsonModule": true,
"moduleResolution": "node",
"downlevelIteration": true,
"allowSyntheticDefaultImports": true,
"skipLibCheck": true,
"paths": {
"~/*": ["./src/*"],
"test/*": ["./test/*"],
"*": ["./typings/*"]
},
"lib": ["es2015", "es2016", "es2017", "es2018", "esnext", "dom"],
"target": "ES2020"
},
"include": ["src", "typings"],
"exclude": [
"node_modules",
"public",
"lib",
"./src/**/__tests__/*.legacy-unit-test.ts",
"./src/**/__tests__/*-itest.ts"
]
} |
|
@stevehollaar any chance you could share code that reproduces the issue? That would help us out a ton |
Unfortunately the codebase is proprietary and I wasn't able to isolate a small repro. I ended up debugging this by adding a console.log line: console.log({source, sourceType });in reportIncompatibleError(ts.Diagnostics.Type_at_position_0_in_source_is_not_compatible_with_type_at_position_1_in_target, sourceIndex, i);That gave me: just prior to the I think there must have been something funky about the way types were shared across module boundaries (possibly related to a circular reference?), as when I tried to repro in the playground, I could not. My "fix" was to explicitly type some exported objects with a shared interface, instead of leaving the type as implicit. I hope this helps! |
|
I'm getting something very similar, but not exactly the same. It compiles fine with 4.1.5 but fails with the error below in 4.2.2. We are using webpack and I'm logging the ts file name as it's being processed, and unfortunately, it's not always happening on the same file. I don't have an easy repro, this solution is proprietary and also contains thousands of typescript files. At first I thought it was when exporting an enum where the enum's values were strings. I noticed the ones that it was crashing on were strings using a single quote and not a double quote, so I changed it, and it seemed to no longer fail on that file. However, I'm no longer certain that's the issue as it's now failing on a file with a large exported class. This class has no members that are strings, although it does use strings in one method, and those strings have single quotes. It's too much to change every file in the project as a test, but this seems like correlation but not necessarily causation anyway. At this point, we are rolling back to 4.1.5.
|
|
I had same problem. For me it was that I used string as an enum instead of using the actual enum as value. |
|
@heikkis , We use them all over the place. The language allows it: https://www.typescriptlang.org/docs/handbook/enums.html. |
|
I'm having the same error as @ItWorksOnMyMachine. And I have a small reproduction repo: https://github.com/flybayer/tsc-broken (boilerplate for a new Blitz app)
|
|
In my case, I had code like this that crashed with a 2626 that was hard to debug: import { defineMessages } from 'react-intl';
type UserSource = 'google' | 'slack' | 'microsoft'
type SourceInfo = {
key: string;
icon: ReactNode;
label: { id: string; defaultMessage: string; description: string };
};
const messages = defineMessages({
slackProvider: {
id: 'fabric.elements.user-picker.slack.provider',
defaultMessage: 'Slack',
description: 'This external user is sourced from Slack provider',
},
});
// @ts-ignore
const SourcesInfoMap = new Map<UserSource, SourceInfo>([
["slack", { key: "slack", icon: <SlackIcon />, label: messages.slackProvider }]
]);The code doesn't run but I hope it gives you enough idea to tell what the issue is about. The weird thing is that it crashed even with that It's possible there was some issue in the original code that was uncovered by the update to TypeScript 4.2. |
|
I ran across this with svelte-check, and I can share my code. This commit: rpavlik/openxr-changelog-maker@7711de4 produces this: Unfortunately I am not good enough at ts to figure out what's actually causing the problem or to narrow it down. Changing my dependency from |
|
This is still happening to me with 4.2.4. Same error: I don't know how to reproduce it - I added a few lines of code to my app which was essentially adding a new icon, something I've done 20-30 times now with no issue. After adding this code, I get this error. Edit: there was an actual Typescript error that I fixed in my code to resolve this, but the crash was still happening. It involved some logic with looking up/iterating over a |
|
Just stumbled upon this too, looks like it was the same issue @bscaspar had: getsentry/sentry@5b78211#diff-d8015cdd3c4c2b662a481d12aae7ff2f2a0bd8d48021a0a369cbd4f06229a2b8L4-R9 |
|
Version 4.2.4 same error. Any idea how to debug it? |
For me there was an actual typescript error which caused the crash, so I had to debug it the old fashioned way - add changes one at a time until the crash identified the problematic code. Of course there doesn't seem to be enough evidence to confirm that TS errors are the only cause so it may be something that would compile completely fine normally. Good luck! |
|
@bscaspar Thank you. Yes it was an error in TS but not sure where exactly. Maybe SWR lib typing. Sad the lib cant produce some kind of error trace. |
|
fyi - I reverted to version "typescript": "4.0.2" (v. old, but was just what was mentioned in Google search results), and it spat our an error trace with line numbers! I can see that it is an issue with assigning types. |
|
Also getting this crash with 4.2.4. |
|
The second commit in the PR has solved the crash. |
|
I had the same issue, in my case it was because of passing array to Map constructor. Consider this case:
here in return statement progress appears to be not a number as I expect, but an object UploadProgress. |
|
I was on |
|
I ran in the same issue and I also had a wrong definition of a type i.e. Wrong export interface MyInterface {
ct: "contenttype1" | "contenttype2" | undefined
}Correct export interface MyInterface {
ct?: "contenttype1" | "contenttype2" | undefined
}The question mark for undefined type definition |
Bug Report
Regression in
v4.2.1-rc(EDIT: also an issue inv4.2.2), tsc fails to compile with an errorDebug Failure. Unhandled Diagnostic: 2626. It worked fine inv4.2.0-beta🔎 Search Terms
🕗 Version & Regression Information
v4.2.1-betaandv4.2.2-rcI was unable to test this on prior versions because _______⏯ Playground Link
Playground link with relevant code💻 Code
// I don't have a simple reproduction, this occurs in our ~60,000 SLOC codebase which is 50% Javascript using checkJs modetsconfig:
{ "compilerOptions": { "target": "es5", "lib": ["dom", "dom.iterable", "es2020"], "allowJs": true, "checkJs": true, "skipLibCheck": true, "esModuleInterop": true, "allowSyntheticDefaultImports": true, "strict": true, "forceConsistentCasingInFileNames": true, "module": "esnext", "moduleResolution": "node", "resolveJsonModule": true, "isolatedModules": true, "noEmit": true, "jsx": "react-jsx", "noFallthroughCasesInSwitch": true, "downlevelIteration": true, "importHelpers": true, "strictNullChecks": true, "noImplicitAny": false, "baseUrl": "src" }, "include": ["src"], "exclude": ["cypress", "src/**/__tests__/*.test.*"], "typeAcquisition": { "include": ["jest"], "exclude": ["chai", "cypress"] } }🙁 Actual behaviour
TSC crashes and fails to compile
🙂 Expected behaviour
It should compile, which worked in v4.2 beta
The text was updated successfully, but these errors were encountered: