Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Scripts: Add TypeScript support to linting command #27143
Scripts: Add TypeScript support to linting command #27143
Changes from all commits
1b6d2cc
5572871
d98c1bd
2dfaec3
9a1b199
8df1ea2
151cf38
94650a3
ae3a72c
f2baa50
2a9d1e4
d2659f6
e613b0f
03fe41c
c400bf0
27f8ba2
3013d31
6fd8aa8
0c27d6b
3057c4c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
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.
It depends how you look at this ESLint warning 😃 We bring React API from
@wordpress/element
that acts as a proxy. It wouldn't be that bad idea to re-export React types used from@wordpress/element
to align with how you use code.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 agree up to a point.
We looked at doing that and it was a nightmare at the time and would've required a lot of maintenance effort for little or no benefit. There's no way to work nicely with types in the module import/export system in JSDoc. We would've had to manually re-export every single type (with their type arguments!) one by one via JSDoc.
Now that we're allowing some TypeScript, it may be more feasible to re-export all the types, but I haven't looked in many months. It still won't be as easy as something like
export type * from 'react'
as far as I know.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.
Unless there is some way to let ESLint know that it should give itself a break when seeing
import type
when processingno-restricted-imports
🤔Let's see: eslint/eslint#13758, typescript-eslint/typescript-eslint#2661.
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 we should list React as peer dependency in that case? There are more packages that would require the same handling.
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 reviewed all the changes again.
It won't scale with so many types required from React or Reakit 🙁
Should we at least disable this rule for all
packages/**/types.ts
files? Ideally, the rule shouldn't error for type imports in the first place.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 think we should just disable those rules for
packages/components
... G2 imports a lot from reakit as well, outside of typescript files.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.
We could as well remove those checks for
react
andreakit
if that becomes an issue. Although, my initial comment still applies. Technically speaking both those libraries are implementation details and shouldn't leak outside of@wordpress/element
(react
) and@wordpress/components
(reakit
). If there is no way to re-export the types that are used in other packages, then we shouldn't fight with the linter and disable the rule as a primary solution. We better remove the rule that becomes hostile.