tsconfig.json option to ignore error TS2307 (or any specific error)

[pferreir]

🔍 Search Terms

• TS2307
• Ignoring specific error

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

In our project we're using some convenience babel magic to add "virtual" packages which inject data into the client application. E.g.

import staticURL from 'indico-url:plugin_vc_zoom.static';

(fetches a URL from the backend's blueprint map)

This is obviously not appreciated by TypeScript, although it's not an issue in the end because we transpile it using Babel. On the other hand, VS Code does complain about it because TS does. Having the VS Code integration is useful and we'd like to continue using it and mute this particular error.

Right now the only option we have is to do something like:

// @ts-expect-error URL import
import staticURL from 'indico-url:plugin_vc_zoom.static';

... which is not great, especially if you end up in a file which has several of those.

Hence, it would be very useful if we could have an option to mute a particular error, or at least something which lets us tell Typescript that we don't want to see errors about unresolved modules (we get those from ESLint anyway).

I found this old discussion, from which there was no conclusion. Maybe there's something new?

📃 Motivating Example

"You're now able to silence particular errors, which is especially useful if you are already using a dedicated linting tool such as ESLint and want to have full control over which errors you see."

💻 Use Cases

1. What do you want to use this for?

• Development in a large project where we are using also Babel + ESLint

2. What shortcomings exist with current approaches?

• Typescript is used both as a transpilation and static checking tool (by VSCode). It obviously complains about missing modules, which is good, and that would be fine if we were not depending on it also for VS Code "linting". I have no way to silence particular false positives unless I do so line by line.

4. What workarounds are you using in the meantime?

• Silencing errors line by line with // @ts-expect-error, which is far from ideal.

[MartinJohns]

Why not just tell TypeScript that these are valid module imports, instead of hiding the error? Create a .d.ts file and add this line: declare module "indico-url:*";

It's better to work with the tools instead of against them. The problem especially with ignoring "any specific error" is that these errors still happen, and can still cause the parsing of the code to trip.

[BalaM314]

Add

declare module "indico-url:*.static" {
	export const staticURL: string;
	export default staticURL;
}

to a declaration file, this will tell typescript that any module of the form indico-url:*.static exists and has a default export of type "string".

[jcalz]

Duplicate related to #19139

[MartinJohns]

@jcalz That issue is about being able to distinguish between errors when using @ts-ignore, but this issue seems to be about being able to globally hide errors (using the tsconfig).

[pferreir]

Thanks everyone, that seems to work. I had no idea you could use wildcards in module names. I'll close the issue.