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. https://github.com/underfin/vite-plugin-vue2/pull/125/files |
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. |
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. |
For those who are still struggling, especially if you live in a monorepo (like Lerna or Pnpm), my colleague has found a nice workaround Putting in Helped me when Typescript tried to compile a neighboring project |
That solves part of the problem: (if what you say it's true 🤞 ) with this particular But you are still forced to first generate declaration files for that less strict project. The best way (from DX perspective) would be to just rely on the existing |
|
|
|
I wrote this workaround script that solves this without needing to relax the TypeScript configuration of your project. It adds a @ts-nocheck directive to the top of all problematic files of the 3rd party libraries, essentially silencing the errors when your project is compiled. You can run it automatically on install by adding this to the
import { readFile, writeFile } from 'fs/promises';
import { join } from 'path';
type PackageConfig = {
// Package name as it appears in node_modules
name: string;
// Base directory within the package where source files are located
sourceDir: string;
// List of problematic file paths relative to sourceDir
problemPaths: string[];
};
const PROBLEMATIC_PACKAGES: PackageConfig[] = [
{
name: '@solana/spl-token',
sourceDir: 'src',
problemPaths: [
'extensions/tokenGroup/state.ts',
'extensions/transferFee/instructions.ts',
'extensions/transferHook/instructions.ts',
'extensions/transferHook/seeds.ts',
'extensions/transferHook/state.ts',
'state/account.ts',
],
},
];
async function addTsNoCheck() {
try {
const rootNodeModules = join(__dirname, '..', 'node_modules');
for (const pkg of PROBLEMATIC_PACKAGES) {
const packagePath = join(rootNodeModules, pkg.name, pkg.sourceDir);
console.log(`Processing ${pkg.name} in ${packagePath}`);
for (const problemPath of pkg.problemPaths) {
const fullPath = join(packagePath, problemPath);
try {
const content = await readFile(fullPath, 'utf-8');
if (!content.includes('// @ts-nocheck')) {
const newContent = `// @ts-nocheck\n${content}`;
await writeFile(fullPath, newContent);
console.log(`Added @ts-nocheck to ${fullPath}`);
} else {
console.log(
`@ts-nocheck already present in ${fullPath}`
);
}
} catch (err: any) {
if (err.code === 'ENOENT') {
console.warn(`File not found: ${fullPath}`);
} else {
console.warn(`Could not process ${fullPath}:`, err);
}
}
}
}
console.log('Successfully processed all packages');
} catch (err) {
console.error('Error processing files:', err);
process.exit(1);
}
}
void addTsNoCheck(); |
|
Can't use verbatimModuleSyntax atm if even one package has a bad setup import (in my case expo-modules-core). |
|
I don't understand what the argument would be for not allowing the programmer to prevent type checking of node_modules. Honestly it is completely obvious that this should be supported. |
I have the same issue. As soon as I turned on verbatimModuleSyntax, it started type checking dependencies. |
|
@hematy61 Probably you have an unused import that was previously being trimmed via the default "Import Elision" behavior. VMS turns that off. If you trim it manually (delete the line, delete the binding, or mark the import/binding with After trying this, if you still find that VMS increases the scope of the checker, please provide a minal repro. Because I think that would be new information and potentially a bug. |
and others
Uh oh!
There was an error while loading. Please reload this page.
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: