Feature Request: allow exclusion of node_modules when skipLibCheck is false
## Search Terms `skipLibCheck node_modules`, `skipLibCheck` All I've found is this lonely [SO post](https://stackoverflow.com/questions/49985943/skip-library-check-only-in-node-modules). As that user notes, there are a lot of posts around Angular and excluding node_modules from typechecking on one dimension or another, but they all end up suggesting turning _on_ `skipLibCheck`. ## Suggestion Allow the exclusion of files in node_modules (regardless of their inclusion in the Project) from lib checking when `skipLibCheck` is set to `false`. ## Use Cases I want to be able to typecheck _my own_ `.d.ts` files without being responsible for all of the types my dependencies import. My local configuration is `strict` and it may be that the types provided in my packages were not intended `strict`ly, or other configurations in my local JSON run up against the way other packages have written theirs. I am assuming the counterargument is that it's all-or-nothing, but then why do `.ts` files that _rely on_ `.d.ts` files typecheck fine when my `.d.ts` files are not typechecked? Can't that behavior be applied to definitions in node_modules? ## Examples Not sure how to show an example here. I would like to be able to run `tsc --noEmit` on my codebase and get errors for my own definitions files without having a bunch of noise from unfixable errors in `node_modules/@types` etc. ## Checklist My suggestion meets these guidelines: * [x] This wouldn't be a breaking change in existing Type
Posted by bensaufley on Mar 20, 2019, 7:23 PM
Tags
Related issues
- struct's lifetime requirements can be bypassed via covariant field assignment
- Proposal to Reorganize the Moderation Team and Review Moderation Policies
- Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
- proposal: container/...: generic collection types
- Better Custom Endpoint BYOK
- A concrete policy for backward compatibility until Godot 5.0
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
github (Other)
struct's lifetime requirements can be bypassed via covariant field assignment
Proposal to Reorganize the Moderation Team and Review Moderation Policies
Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
proposal: container/...: generic collection types
Better Custom Endpoint BYOK
A concrete policy for backward compatibility until Godot 5.0
New MTP models not supported
Tracking: 429 / Capacity Issues
Feature Request: allow exclusion of node_modules when skipLibCheck is false
## Search Terms `skipLibCheck node_modules`, `skipLibCheck` All I've found is this lonely [SO post](https://stackoverflow.com/questions/49985943/skip-library-check-only-in-node-modules). As that user notes, there are a lot of posts around Angular and excluding node_modules from typechecking on one dimension or another, but they all end up suggesting turning _on_ `skipLibCheck`. ## Suggestion Allow the exclusion of files in node_modules (regardless of their inclusion in the Project) from lib checking when `skipLibCheck` is set to `false`. ## Use Cases I want to be able to typecheck _my own_ `.d.ts` files without being responsible for all of the types my dependencies import. My local configuration is `strict` and it may be that the types provided in my packages were not intended `strict`ly, or other configurations in my local JSON run up against the way other packages have written theirs. I am assuming the counterargument is that it's all-or-nothing, but then why do `.ts` files that _rely on_ `.d.ts` files typecheck fine when my `.d.ts` files are not typechecked? Can't that behavior be applied to definitions in node_modules? ## Examples Not sure how to show an example here. I would like to be able to run `tsc --noEmit` on my codebase and get errors for my own definitions files without having a bunch of noise from unfixable errors in `node_modules/@types` etc. ## Checklist My suggestion meets these guidelines: * [x] This wouldn't be a breaking change in existing Type
Comments (0)
No comments yet. Start the discussion.