Skip to content
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

Be able to change skipLibCheck flag in command line #45691

Closed
5 tasks done
MarcCelani-at opened this issue Sep 2, 2021 · 4 comments
Closed
5 tasks done

Be able to change skipLibCheck flag in command line #45691

MarcCelani-at opened this issue Sep 2, 2021 · 4 comments
Labels
Duplicate An existing issue was already created

Comments

@MarcCelani-at
Copy link

Suggestion

Add a new --skipLibCheck [bool] flag to tsc when using --build. This flag would override the skipLibCheck value in all tsconfig.json files for all projects checked in the build.

πŸ” Search Terms

performance
skipLibCheck

βœ… Viability Checklist

My suggestion meets these guidelines:

  • 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 feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

We are interested in leveraging skipLibCheck when using the typescript checker in order to avoid expensive checks on large .d.ts files from external libraries that we include as node modules. That said, we recognize that there is some danger in skipLibCheck. For example, a third party module may have been checked with a different version of tsc, or with different levels of strictness. We would feel more comfortable with a workflow that allows us to check libs when we import a new version of a node module, upgrade the tsc compiler, or change compiler flags.

In order to do this, we request that tsc support a --skipLibCheck (bool) flag when using --build. This flag would override the skipLibCheck compiler option in the tsconfig.json file (and the tsconfig.json file for all project references).

πŸ“ƒ Motivating Example

As a motivating example, node_modules/@types/lodash/ts3.1/common/common.d.ts, a dependency we take in all of our projects, takes 1.25 seconds to check on my dev machine. Without skipLibCheck, the overhead of splitting our monorepo into smaller projects is too high to justify the work.

πŸ’» Use Cases

We generally want to set "skipLibCheck": true in our tsconfig.json files, but we want a workflow that allows us to check libs when we import a new version of a node module, upgrade the tsc compiler, or change compiler flags.

@MartinJohns
Copy link
Contributor

Duplicate of #25613.

@MartinJohns
Copy link
Contributor

In the meantime you could create a second tsconfig file that extends your existing one, and just changes the skipLibCheck value. Then when executing the compiler point to your second config file.

@MarcCelani-at
Copy link
Author

MarcCelani-at commented Sep 2, 2021 via email

@andrewbranch andrewbranch added the Duplicate An existing issue was already created label Sep 2, 2021
MarcCelani-at added a commit to MarcCelani-at/TypeScript that referenced this issue Sep 2, 2021
Summary:
Many large composite projects rely on skipLibCheck to improve build times.
However, skipLibCheck does introduce some risk that projects miss typescript errors
in new node module versions they install.

This is in response to Issues microsoft#45691, microsoft#25613, and microsoft#41185

Test Plan:
New tsbuild unit test scenario that tests overriding the skipLibCheck value with a flag.
Validated with verbose output that the actual build overrode the value in the tsconfig.json file.
@typescript-bot
Copy link
Collaborator

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

4 participants