Disable type checking for node_modules entirely #40426
Comments
Okay, this is one of the reasons you might use
This is the opposite of the scenario you're describing. The library author has shipped incoherent types, and who's to say what the correct interpretation of that is? It is good that TypeScript errors here, even if it is an overall terrible user experience. "Disabling type-checking" can mean a lot of things. Having the package come in as |
|
I want to mention after reading this a second time: shipping |
|
Yeah there are lots of good reasons to actually have the sources of a library available, I like to explore them in my IDE sometimes or maybe while debugging etc. But I don't actually want to have them checked by the typescript compiler, hence the skipLibCheck. It's just so confusing to me why the skipLibCheck is only intended for typing files and not for |
RyanCavanaugh
added
Awaiting More Feedback
|
This scenario is going to be completely busted for a lot of reasons. It seems like the option one would really want, if they found themselves stuck in it, would be to say that |
|
I think If you are importing |
|
Could there be a way to just silence errors from certain paths? I don't want to make a whole import from node_modules type Noting that a single type check fail would break CI unless I silence it some how. |
|
(I tried |
|
I am having a very similar issue with a node_module that is included locally in package.json with a path: |
Just ran into this exact scenario trying to type check my build scripts. Seems like not many people do that so some build-related modules have issues that go unnoticed. |
Importing from typescript source files distributed with a module causes user projects to type check those source files using the tsconfig of the user project rather than that of the module, with stricter settings raising errors that would otherwise go unnoticed. See microsoft/TypeScript#40426
|
Here's an example of a project that seems to be doing something benign, simply importing an interface for the sake of type checking. But the import path points to distributed typescript source files rather than the compiled JS. And while there aren't any issues with the types of that module, because my project has stricter type check settings it causes issues. |
Importing from typescript source files distributed with a module causes user projects to type check those source files using the tsconfig of the user project rather than that of the module, with stricter settings raising errors that would otherwise go unnoticed. See microsoft/TypeScript#40426
Importing from typescript source files distributed with a module causes user projects to type check those source files using the tsconfig of the user project rather than that of the module, with stricter settings raising errors that would otherwise go unnoticed. See microsoft/TypeScript#40426
|
I'm having this problem with the lib tst-reflect/tst-reflect-transformer: "TS6133 declared but value never read" Compiler opts, ran with ttypescript's |
|
We have been forced to disable The code compiles properly, and works at runtime. However, we wish to have Being unable to enable any strict typing, solely because we consume third-party packages that don't meet the same strictness, and of which we have no leverage for change:
We have a manual process that is sometimes applied:
I had suggested something similar to this : #44205. But it was rejected as "configuration issue". |
|
Can we please get a flag to suppress any error messages from files originating from
An example of unwanted error: Okay, so? I don't really mind that there are type errors on the libraries we use, I only mind that there are type errors on the codes that we wrote anywhere else other than I have 121 errors all of which are from Can someone explain what's the reasoning why we would want to be blocked by errors coming from |
|
My project is fully in js but I do use IntelliSense with strict typing so that I get early warnings when mistakes have been made. But since both Normally this wouldn't be a huge issue, but I have also enabled I also wish to include type checking in CI, but this makes that impossible without writing some sort of plugin to filter all unnecessary errors. As far as I'm aware, there's a few options to fix this:
But neither of these seem like a satisfying solution to me. If it were possible to add a list of paths to the tsconfig/jsconfig similar to the |
|
The irony is that this issue is not about no-name packages. Microsoft authentication library for js does throw an error during build under strict ts mode: Btw, check out their average code quality) Declared return type - 'Account', actual return type - 'Account | null'. |
|
@snowinmars That library has a correct An external library not having |
Msal can be imported in two ways:
It's about Technically, one can say, that that's what prebuilds are for. But I would not agree: if developers doesn't want the source to be linked, they do not include it to npm package. So, it's a legal way to use a library, that just doesn't match with another's developer way. If typescript compiler could solve this kind of issues, that'd be cool. P.S. There is a |
|
If the MSAL authors are telling you to import the TS sources directly from their packages, please tell me where so I can go tell them to fix their docs. This isn't a supported scenario and there's no end of problems this will cause. |
OP was specifically referring to importing
and
|
I already tried that and in several cases it didn't help. Your use of the word "effectively" seems to acknowledge that there are caveats, and so does your comment on #47387.
I think maybe we have slightly different ideas of what constitutes "true problems". You seem to be viewing it from a more purist perspective of whether there are genuine compilation issues within the codebase. This is of course perfectly valid and quite understandable given the nature of your work on TypeScript! In contrast however, I am more concerned with being able to implement needed functionality in my codebase whilst having its CI and linting set up for a pragmatic balance between theoretical correctness and being able to get my job done. That means that if I encounter some errors which I know are not serious issues in my context (for example if they relate to library code which I'm not even using), then as an experienced software engineer I want to be able to make a judgement call on the risk, temporarily remove those obstructions by downgrading them to warnings, and then return to them later as lower priority concerns. I suspect many of the people following this issue and similar ones like #44205, #30511, #47387 are closer to my position than yours, otherwise we wouldn't be seeing so many 👍 and ❤️ emojis on the OP.
Specifically but not exclusively. Notice the repeated use of the word "might".
Two examples were given, the first of which had nothing to do with libraries providing typescript source files. And this was under a "Use cases" header, after the original issue title and "Suggestion" header, neither of which mentioned anything about libraries providing them. But regardless of the OP's intentions, my point is that there definitely two orthogonal topics here, and we need to consider the ability to selectively silence or downgrade errors from selected paths, regardless of whether those errors are being caused by |
|
Please redirect me if this isn't the right thread to bring this up; searching the issues on this topic is hard because I have a dependency with an {
"type": "module",
"main": "index.js",
"module": "index.js",
"files": [
"index.js",
"index.d.ts",
"index.d.ts.map",
"index.ts"
]
}For reasons I cannot understand, when I import it as a named package (e.g., I can work around it temporarily by manually editing the dependency's Is this something already being talked about above? It seems like if TSC just defaulted to At the least, it seems like the docs should be corrected if this is intended behavior (docs say that |
|
There seem to be loads of libraries causing this issue when a project or its dependencies depend on them. In this case, I understood, there is not much you can do about it except being less strict with your own code. This, unfortunately, will lead to issues sneaking into your own code. It would be nice to be able to enforce strict type checking on your own code to keep the quality high, but to accept the problems in dependencies that you have no realistic possiblity to fix. |
|
@avidj the only option I see is to fork the library and generate the *.d.ts files yourself. |
|
I turned on First, I had several errors in my But then I discovered the The argument that it is dangerous to allow developers to exclude I NEED to be able to type-check my own project's To any TypeScript contributor resistant to giving we developers what we're asking for here, I seriously have to say "shame on you." Stop making it difficult for me to get better quality in my own projects. Stop it. Please. Just stop. I have work to do. I can't fix the world. I can't put pressure on these third-party packages. I'll lose my job or my contract if I don't deliver. I simply don't have time or energy to help make the world perfect. I learned to program almost 4 decades ago. I like sharp knives. Please give me sharp knives. I know how to use them. I have the scars to prove it, and I don't cut myself much any more. And if I understand a system and can control it, I can heal from the cuts quickly, anyway. While I wouldn't like it, I'd be content enough if I had to silence I most humbly and abasedly beg you all on bended knee and with bowed head to freaking help me get my job done. P.S. If you want to do the world a favor, make some non-strict options in subsequent versions of TypeScript no longer able to be off. Just start picking some to be strict always and throw errors if the option is even present in the |
|
I also strongly believe the most pragmatic path forward would be the skip type checking files under a The workaround I've found for this annoyance is to leverage project references to prevent type checking certain problematic dependencies. The |
|
I'm speculating a bit here, but I would guess that "skip node_modules" would be non-trivial to implement. The compiler has to look at type definitions in node_modules for any dependency you reference, so it has to do some type checking. I suspect the best that could be done is something like "ignore warnings in node_modules" or perhaps "ignore non-critiral errors in node_modules". This is a bit risky though because it means the compiler would need to make some reasonably guesses about what types it should return in these situations. |
|
So I use TypeScript type checking without the need to compile, i.e. I am manually writing all my types in For a project of mine that I use Here is what I did to run import { ts } from "typescript"
import { fs } from "fs";
import { path } from "path";
export const runTscInProjectRootOutsideNodeModules = () => {
const absolutePathToProjectRoot = path.resolve("./");
const absplutePathToNodeModules = path.resolve("./node_modules");
const absolutePathToTsConfig = path.resolve("./tsconfig.json");
const parseJsonResult = ts.parseConfigFileTextToJson(
absolutePathToTsConfig,
fs.readFileSync(absolutePathToTsConfig, { encoding: "utf8" })
);
const tsConfig = ts.parseJsonConfigFileContent(
parseJsonResult.config,
ts.sys,
path.resolve("./")
);
const program = ts.createProgram({
rootNames : tsConfig.fileNames,
options : tsConfig.options,
});
const diagnostics = ts.getPreEmitDiagnostics(program);
const diagnosticsInProjectRootOutsideNodeModules = diagnostics.flatMap((diagnostics) => {
const {file} = diagnostics;
if (file === undefined) throw Error(); //@TODO I have no clue what this case is for
const absolutePathToCurrentFile = path.resolve(file.fileName);
if (
absolutePathToCurrentFile.startsWith(absolutePathToProjectRoot) &&
!absolutePathToCurrentFile.startsWith(absplutePathToNodeModules)
) return [diagnostics]
return [];
})
diagnosticsInProjectRootOutsideNodeModules.forEach(({
file: sourceFile,
start,
code,
}) => {
if (sourceFile === undefined) throw Error();//@TODO I have no clue what this case is for
if (start === undefined) throw Error();//@TODO I have no clue what this case is for
const fileName = sourceFile.fileName;
const relativePath = path.relative(absolutePathToProjectRoot,fileName);
const {character,line} = sourceFile.getLineAndCharacterOfPosition(start);
console.log(`${relativePath}:${line + 1}:${character + 1}`,`TS${code}`);
})
if (diagnosticsInProjectRootOutsideNodeModules.length > 0) process.exit(-1);
} |
So, I'm using the Unlike some stuff mentioned here, the types from that package are all perfectly good. But, if any of the internal I tried importing it directly to my // chevrotain.d.ts
import type {
MixedInParser as ChevrotainMixedInParser
} from 'chevrotain/src/parse/parser/traits/parser_traits'
declare module 'chevrotain' {
type MixedInParser = ChevrotainMixedInParser
}This still produced a error. So then, I set So, while I never imported a source library's Is there another way to do this? Or is there a way for a source libraries |
|
@dejayc be constructive. |
|
As luck would have it, despite debugging for hours prior, I figured out my issue 10 seconds after posting this comment. I turns out I was indeed missing something here. I was importing a TS file when I should've been importing a JS file. Replacing import { AuthorizationParams } from '@auth0/auth0-spa-js/src/global';with import { AuthorizationParams } from '@auth0/auth0-spa-js';solved my problem! 🎉 Feel free to delete this comment — I just left it in case it helps a fellow straggler. |
|
any solution? |
Thank you very much @hudson155 , this fixed my problem. |
|
I have a monorepo. Similarly to other people here, I wanted to implement a type check step and have run into this issue. |
Adding my 2 cents, because I have the same issue with a monorepo and wanted to add more context. The whole dilemma actually started when I decided to move out of cross-project path aliases (which is considered a misuse of path aliases as stated now in the docs) and rely on proper package imports via Yarn. I first made sure my projects rely on Node16 I thought I'll instruct TS to use the library's source code instead and skip the compilation step completely, making the feedback loop instant. So I modified the However, the library was written some time ago, with not-that-strict rules. And now the app that's using it is throwing compilation errors, because it's tsconfig is stricter than the library's. I now have to either:
This variation of the problem is not that severe as the original one, because at the end of the day I am in control of the whole repository. But as you can see you don't necessarily need to deal with faulty packages to encounter this issue! |
|
Just wanted to +1 the above comments. Not sure if perhaps it deserves a separate issue thread entirely, but like @akwodkiewicz, I have a monorepo (pnpm, turborepo, typescript, Next.js). Currently I build all of those packages, as well as emit However, I no longer actually need to build these packages, as the app is fully capable of transpiling them. Furthermore it turns out the app transpiling is quite a bit faster than running build in each package. This is great, big win. Problem is, now I have no way of typechecking my packages individually (as they all use workspace links and each of them would now point to a Like others above, if I try to typecheck a single package, it will end up typechecking the dependencies of that package as well, which is both redundant (since I typecheck these in separate processes) and potentially buggy, as the I'd love to be able to simply exclude or skip, but that doesn't seem to work (e.g. Are there any other suggestions for monorepo/workspace users running into this issue? |
|
I have a frontend and a backend both written in TypeScript. The backend runs on Bun, and frontend is built with Vite. Using the This works. My only remaining problem is that the frontend's build process is now spitting out errors from the backend. It's obviously missing all of the backend libraries, types for Bun etc. In my case, none of it matters, as none of that code is going to be included in the front-end build anyway (because Please allow an option to either A) only show errors from within the project, ie. from files included in the (which would make a sensible default IMO, but it's debatable I guess) or B) allow specifying an I respectfully disagree with the notion that the above is "really dangerous". It is no more dangerous than using TypeScript is a tool - please let us apply it selectively. |
and others
Search Terms
skipLibCheck
node_modules
ignore library
exclude
Suggestion
Either a new option or the existing option
skipLibCheckshould be able to disable type checking for node_modules.Use Cases
A library author might have a faulty import or might only provide typescript files for his library and not transpiled code. As a user of this library I want to be able to disable type checking for a library (or all) because I trust this library has been tested enough in other ways.
Another issue where I found a library shipping ts files and causing errors for the user: #15363
The response at the end is very relevant
Originally posted by @victornoel in #15363 (comment)
Examples
I had the case that a library came with a
dist/folder and almost all types were perfectly arranged in .d.ts files. But one file was making an import from../index.d.ts(which seems to be for development purposes, the lib main file isdist/index.d.ts) which in turn then importedsrc/ClassA.tsThe library author used a different tsconfig and didn't use strict type checking, but I do and that's why the type check fails for me, because now the typescript source files of the library author are type checked.
Checklist
My suggestion meets these guidelines (in case of a new option):
The text was updated successfully, but these errors were encountered: