tsc may fail to report error when `file.js` & `file.d.ts` coexist, even when `@ts-check` is added on `file.js`.

[hkleungai]

🔎 Search Terms

ts-check

🕗 Version & Regression Information

• This changed between versions 4.4.4 and 4.5.2

⏯ Playground Link

Meaningless to paste playground link I guess, when it is about typechecking plain javascript file

💻 Code

src/main.js

// @ts-check
export const x = parseFloat(3.14);

src/main.d.ts

export const x: number;

{
    "compilerOptions": {
        "rootDir": ".",
        "outDir": "./dist",
        "target": "esnext",
        "types": [],
        "sourceMap": true,
        "strict": true,
        "isolatedModules": true,
        "skipLibCheck": true,
        "allowJs": true,
    },
    "include": [
        "src/*.js",
        "src/*.d.ts",
    ]
}

🙁 Actual behavior

No error.

🙂 Expected behavior

src/main.js:3:29 - error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.

3 export const x = parseFloat(3.14);
                              ~~~~


Found 1 error.

Additional information about the issue

Note that the error will reappear when "include" is reorder as ["src/*.d.ts", "src/*.js"].

Also note that https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html mentioned no such behaviour change regarding @ts-check.

[MartinJohns]

.d.ts files take priority over .js files, because they already provide all the type information. You shouldn't have them both at the same time. You can enable --skipLibCheck to ignore the .d.ts file, or let TypeScript generate the .d.ts file from your .js file.

[hkleungai]

You can enable --skipLibCheck to ignore the .d.ts file

skipLibCheck does present in my above reproduced code... And yet I am still seeing the same "bug".

.d.ts files take priority over .js files

I cannot find any reference on v4.5 release note or elsewhere in typescript doc to validate this statement, although it indeed is my first guess on how it break.

If the priority thing is true, I wish the documentation will help make it more clear, instead of making this "unannounced change" take effect between versions.

I guess the "reorder hack" also confuse me a bit.. Like, if type checking is meant to fail in this use case, I would expect tsc emit error no matter how the "include" array is ordered..... The fact that this hack works, seems to me is a sign of a long-standing inconsistency within tsc.