-
Notifications
You must be signed in to change notification settings - Fork 13k
Enable noUncheckedSideEffectImports
by default
#62443
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR enables the noUncheckedSideEffectImports
compiler option by default. The option checks that side effect imports (imports without bindings like import "module"
) can be properly resolved, helping to catch errors where modules cannot be found or resolved.
Key changes:
- Changed the default value from
false
totrue
for thenoUncheckedSideEffectImports
option - Updated compiler logic to enable the flag by default
- Added test suppressions for existing tests that relied on the old behavior
Reviewed Changes
Copilot reviewed 34 out of 34 changed files in this pull request and generated no comments.
File | Description |
---|---|
src/compiler/commandLineParser.ts |
Changed default value description from false to true |
src/compiler/checker.ts |
Updated logic to enable flag by default using !== false instead of !! |
Multiple test files | Added // @noUncheckedSideEffectImports: false directive to preserve existing test behavior |
Test baseline files | Updated error outputs to reflect new default behavior catching side effect import errors |
@typescript-bot test it |
Hey @RyanCavanaugh, the results of running the DT tests are ready. There were interesting changes: Branch only errors:Package: chai-like
Package: splitting
Package: chai-json-schema
Package: react-katex
Package: vue-moment
Package: dirty-chai
Package: redux-shortcuts
Package: react-smartbanner
Package: bmapgl-browser
Package: chai-subset
Package: vue3-carousel-3d
Package: babel-types
Package: chai-string
Package: chai-fs
Package: karma-chai
Package: node/v18
Package: chai-spies
Package: page-flip
Package: rangy
Package: tablesorter
Package: hapi
Package: hapi/v17
Package: chai-arrays
Package: wonder.js
Package: gun
|
@RyanCavanaugh Here are the results of running the user tests with tsc comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Everything looks good! |
import "./extention"; | ||
~~~~~~~~~~~~~ | ||
!!! error TS2307: Cannot find module './extention' or its corresponding type declarations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird, why doesn't this work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we wrote extention
(t) and the file is called extension
(s), lmao
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proof the flag is good
@RyanCavanaugh Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@RyanCavanaugh Here are the results of running the top 400 repos with tsc comparing Something interesting changed - please have a look. Details
|
@RyanCavanaugh Here are some more interesting changes from running the top 400 repos suite Details
|
@RyanCavanaugh Here are some more interesting changes from running the top 400 repos suite Details
|
Is it also time to make the message mention the flag? (I suspect it will be annoying to actually implement, though.) |
It's easy to implement (just need to pass in the context to resolveExternalModuleName) Verbiage? |
Honestly probably it's fine to not. We do need to fix the DT cases, though. Maybe the results mean that we should be ignoring these in declaration files? |
Erroring in .d.ts files is still correct IMO, since if it's not yours it's almost certainly suppressed by skipLibCheck |
#62442 doesn't seem to be going well
Fixes #62421