-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
skipLibCheck: true
is ignored when package's types
field points to a .ts
file (not a .d.ts
declaration file)
#41883
Comments
It has no other effect. It does nothing in |
I think one would intuitively expect no errors from inside For example, the Webpack build in the consumer app works fine, it pulls in the non- The types in the How do we assert to |
There isn't a setting that would cause TypeScript to not issue an error in a |
This circles back to (some issues in) #35822, because we can not consume mixin classes from a package unless the package's |
Without From #17744 (comment) (@justinfagnani):
|
We are interested in making |
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
@DanielRosenwasser Is it possible to make TypeScript skip type-checking source files of libraries (i.e. when their package.json This would make shipping neat features possible, that are otherwise currently not allowed when declaration output is turned on. As an example, all the issues listed in #35822 would be solvable by simply recommending people in those cases to point their The alternatives are to wait an unknown number of years for a solution, or to abandon the cool features. Adding such a solution would be a very simple unblocker for those nice use cases. Of course, if declaration output could be fixed, that'd be preferable, but the pace at which that is happening is very slow, and the alternative suggested solution seems to be a lot easier to unblock many people from using cool patterns. |
If the community starts shipping full source in place of |
This issue, together with #38538, is what we're seeing as well. The core seems to be that that TypeScript checks imported We think that TypeScript just crawls
The first point is a problem – we don't want to see errors from I acknowledge that Some context: besides the use case reported by the OP ( Modern frameworks like Next.js, Gatsby, CRA and others process TypeScript "natively" so it's actually better not to transpile We're using TypeScript as a "linter" only, i.e., |
This is indistinguishable from an intentional configuration. We'd need some more intentional way for you to specify what's "yours" and "not yours" |
@RyanCavanaugh I agree. I intuitively thought that I'd say that "my code" is everything under the current folder (where I imagine it would still be possible to explicitly include those if one wants, like this:
Do you see any glaring holes in this or could it work? |
Actually, while I assumed that (I think I understand what |
I faced this same issue past friday. It's even weird because the library we used had a few TS rules off in its For now, the only workaround we found was to replace the |
This comment has been minimized.
This comment has been minimized.
Tangentially related but Deno 1.17 now supports
Feels similar in spirit to this issue. |
The problem also occurs when the Typescript tries to recompile the source in that case, which seems wrong. |
Just hit this and have no idea how to resolve, no changes to any tsconfig files or updates to typescript or the problematic library but the build is throwing this:
What's the advised way to go about this? Surely it can't be changing all imports to requires that would result a huge diff and seems backwards. This is working fine on another branch and it seems to only be this file that's failing. And yes |
I have the same issue with
It was working with previous version of typescript (4.5) |
If you're using webpack with the new ForkTsCheckerWebpackPlugin({
...,
issue: {
include: [
{ file: '**/*' }
]
}
}) So just including everything makes it work for me again. |
I changed "module" in "compilerOptions" to be "ES2020" from "commonjs" and it seemed to resolve this bug for me.! excluding 'node_modules', setting skipLibCheck to true, and setting types=[] did not work for me, but this did. |
@misantronic That did it for me, thank you very much for dropping by with that :). How did you end up trying that setting? |
tbh, I don‘t remember 😅 I might have looked into the source and found how it would work. |
So what is the status here? I understand that all of the existing settings are working as intended (ie: include, exclude, skipLibCheck). But for the increasingly common use case of using |
For anyone finding this in 2023, using typescript Version |
@deepio I'm still observing this with 5.2.2 and skipLibCheck - did you tweak anything else? |
Nothing material about
There is no setting that causes If you have a There is no setting for ignoring this misconfiguration, since if you're in this state, important compiler settings ( |
TypeScript Version: 3.9.7
Search Terms:
skipLibCheck is ignored
skipLibCheck not working
Code
N/A
Expected behavior:
TypeScript should ignore type errors in node_modules (or skip reporting them? I'm not sure exactly what
skipLibCheck
does).Actual behavior:
When
skipLibCheck
is set totrue
, TS will still have type errors in packages innode_modules
. It seems that this is the case if a package'stypes
field in the package'stsconfig.json
file points to a.ts
file instead of a.d.ts
file.For example, in my project that consumes the
lume
package, there are type errors like these:As you can see the path in the errors are in
node_modules
. Thelume
package'stypes
field points to itssrc/index.ts
file, and hence all the types in that package are based on.ts
files instead of.d.ts
files.Playground Link:
N/A
Maybe I misunderstand what
skipLibCheck
does. What should it do exactly?The text was updated successfully, but these errors were encountered: