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

chore: revive type checker #18172

Merged
merged 23 commits into from Oct 13, 2021
Merged

chore: revive type checker #18172

merged 23 commits into from Oct 13, 2021

Conversation

sainthkh
Copy link
Contributor

@sainthkh sainthkh commented Sep 21, 2021

User facing changelog

N/A.

It's for internal use.

Additional details

  • Why was this change necessary? => I don't know exactly when, but it seems that updating listr to listr2 at fix: Migrate from listr to listr2 #16663 broke the type checker.
  • What is affected by this change? => N/A

Implementation details

  • I've added some @types packages like @types/webpack-dev-server,
  • I changed the version of @types/mocha to 8.0.3 everywhere.
  • As for mocha and jquery types that cause the clash with the bundled types, I deleted the original with patch-package.
    • This might cause some build failures. But it can be fixed by building twice.
    • I had to reference bundled type files to fix the type problems.
    • I had to update patch-package to 6.4.7 to bypass the buffer size bug.
  • I added css-modules-typescript-loader to add type definitions for the included css files.
  • I fixed types in the reporter.
  • I intentionally typed options to any because it's a big change. As we're reusing options argument inside the function code, the names should be changed.
  • I added types for the functions imported to lodash from underscore.string.
  • I updated the awesome-typescript-loader test.
  • I updated type_checker.js to work correctly with listr2.

TODOs for the later PRs

How has the user experience changed?

N/A

PR Tasks

  • Have tests been added/updated? => Is there a way to check the type_check.js is running correctly to prevent things like this?

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Sep 21, 2021

Thanks for taking the time to open a PR!

@sainthkh sainthkh force-pushed the issue-18069 branch 2 times, most recently from e9d7e4b to b8c64e5 Compare September 29, 2021 02:32
@sainthkh sainthkh marked this pull request as ready for review October 1, 2021 02:30
@sainthkh sainthkh requested a review from a team as a code owner October 1, 2021 02:30
@sainthkh sainthkh requested review from flotwig and chrisbreiding and removed request for a team October 1, 2021 02:30
Copy link
Contributor

@flotwig flotwig left a 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"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// "types": ["cypress"]

Comment on lines +77 to +95
// 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)
})
Copy link
Contributor

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.

Copy link
Contributor Author

@sainthkh sainthkh Oct 12, 2021

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

@sainthkh sainthkh requested a review from flotwig October 12, 2021 02:51
@flotwig flotwig merged commit af472b6 into cypress-io:develop Oct 13, 2021
@cypress-bot cypress-bot bot mentioned this pull request Oct 13, 2021
@flotwig
Copy link
Contributor

flotwig commented Oct 13, 2021

Whoops, I missed it before merging, but technically this should have been a chore:, not a fix:. Oh well.

@flotwig flotwig changed the title fix: revive type checker chore: revive type checker Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix type checker
3 participants