-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
chore: revive type checker #18172
chore: revive type checker #18172
Conversation
Thanks for taking the time to open a PR!
|
e9d7e4b
to
b8c64e5
Compare
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.
Thank you so much for identifying this issue and fixing it @sainthkh
@@ -6,6 +6,7 @@ | |||
"sourceMap": false, | |||
"inlineSourceMap": true, | |||
"inlineSources": false, | |||
"types": ["cypress"] | |||
"typeRoots": ["../../../../cli/types"], | |||
// "types": ["cypress"] |
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.
// "types": ["cypress"] |
// https://github.com/cypress-io/cypress/issues/18069 | ||
// To avoid type clashes, some files should be commented out entirely by patch-package | ||
// and uncommented here. | ||
|
||
const filesToUncomment = [ | ||
'mocha/index.d.ts', | ||
'jquery/JQuery.d.ts', | ||
'jquery/legacy.d.ts', | ||
'jquery/misc.d.ts', | ||
] | ||
|
||
filesToUncomment.forEach((file) => { | ||
const filePath = join(__dirname, '../types', file) | ||
const str = fs.readFileSync(filePath).toString() | ||
|
||
const result = str.split('\n').map((line) => line.substring(3)).join('\n') | ||
|
||
fs.writeFileSync(filePath, result) | ||
}) |
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.
I am confused why this is necessary. Can you explain why the commenting/uncommenting is needed?
And can we generate the .patch
files instead of inlining them? Would prefer to avoid it if possible.
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.
Unlike other projects, Cypress type definition should copy definition files(d.ts) and bundle them ourselves because of the clash of mocha and jest test functions(i.e. it
, describe
, etc.). For more info, #7194.
But when we do them, there are 2 copies of mocha and jquery inside our project. Because of that, they cause errors because of the duplicate definitions of global names.
To avoid that, I had to find a way to comment out one of them. I decided to comment the files inside node_modules/@types
folder. I did it with patch files added to the project.
But the problem is that those patches are applied earlier than copying them to the cli/types
. So, the copied version is the commented version. That's why I had to write code above.
I also don't like this solution and thought about other solutions like below:
- Copy the definitions when it is built for production => It seems that there is no prod-build only script. I wasn't confident enough to handle production build script.
- Don't use patch and comment them out on post-install.js => It cannot remove the code inside
post-install.js
. It can comment out already-commented files (i.e. the code will be complicated.) - Creating our own
CyMocha
,CyJQuery
definition. => It was impossible because definitions are tightly coupled. Removing some of them cause unexpected problems.
The conclusion was the code above.
I also hate this. But it seems that this is the simplest solution unless we remove mocha
, chai
from Cypress or make them optional.
p.s. And this solution is not perfect because it can cause temporary build failures in some environments. For example, I have to build twice on my Ubuntu 20.04 to finish it because the build fails somehow for the type failures.
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.
Blergh. Well, it's certainly an improvement over not having the type-checking at all.
This is the type of thing that will be fixed next time there's an issue anyways, so I'm in favor of merging as-is, even with the kludge.
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.
This is actually causing problems now we are upgrading to TS 4.4, the whole project build completely explodes with invalid types. We should revisit this soonish.
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.
Maybe, the problem could be solved by fixing all the type errors when yarn type-check
.
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.
@lmiller1990 I've updated TypeScript to 4.4.4 at #18930. There were some breaking changes at TypeScript. So, it caused many errors.
Whoops, I missed it before merging, but technically this should have been a |
User facing changelog
N/A.
It's for internal use.
Additional details
listr
tolistr2
at fix: Migrate from listr to listr2 #16663 broke the type checker.Implementation details
@types
packages like@types/webpack-dev-server
,@types/mocha
to8.0.3
everywhere.mocha
andjquery
types that cause the clash with the bundled types, I deleted the original withpatch-package
.css-modules-typescript-loader
to add type definitions for the included css files.reporter
.any
because it's a big change. As we're reusingoptions
argument inside the function code, the names should be changed.lodash
fromunderscore.string
.awesome-typescript-loader
test.type_checker.js
to work correctly withlistr2
.TODOs for the later PRs
npm
folder and test utils.any
type. => chore: remove command type todos #20601create
functions like indriver/src/cypress/server.ts
, etc. => chore: makecreate
function on server.ts obsolete #18615.How has the user experience changed?
N/A
PR Tasks
type_check.js
is running correctly to prevent things like this?