-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
[No QA] Standardize type-only imports #32475
[No QA] Standardize type-only imports #32475
Conversation
Lots of changes due to |
@Santhosh-Sellavel Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
do we need screenshots & QA here? @roryabraham |
Prettier is failing @chrispader |
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.
LGTM! One comment but not a blocker
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.
@chrispader Could you add a section in our TS guidelines about these import rules?
I'm not sure it's needed as this is enforced with ESLint 🤔 |
Well we have a couple of rules that are enforced by ESLint but they are also detailed in the guidelines 🤷♂️ |
yep I agree. we should also write about this in the guideline 👍 |
@chrispader Please unresolve this thread 🙏 |
Conflicts & tests fails |
Just for clarification: We decided to wait (for me) to create an upstream PR to fix a problem with this rule, where the |
4a93919
to
c24c897
Compare
Turns out, we don't need an upstream change 🎉 There's a rule for enforcing type specifier style: |
Great, @blazejkustra @fabioh8010 @Santhosh-Sellavel back to you for review |
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 still an issue. Both exports work:
export type {LocaleContextProps};
// or
export {type LocaleContextProps};
For imports:
import type {WithCurrentUserPersonalDetailsProps} from './withCurrentUserPersonalDetails';
import withCurrentUserPersonalDetails from './withCurrentUserPersonalDetails';
// or
import withCurrentUserPersonalDetails, {type WithCurrentUserPersonalDetailsProps} from './withCurrentUserPersonalDetails';
That being said, I don't consider it as huge issue, I'm good with merging as it is now 👍
Yes it is unfortunately. I can't find any rule that enforces this though.. So also in favor of merging anyway |
Merged main and resolved conflicts. Ready for review and merge :) cc @roryabraham |
@chrispader unfortunately we got a toooon of conflicts here. I think we need to sync up in slack and time the merge to happen as soon as conflicts are resolved next time. |
04821e3
to
19eb210
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.
Thoroughly reviewed the whole diff, LGTM 👍🏼
Though, lint is failing |
It looks like when you resolved conflicts you accidentally got rid of your changes in |
@roryabraham |
yes i did. Just added it back |
Reviewer Checklist
Screenshots/VideosAndroid: NativeAndroid: mWeb ChromeiOS: NativeiOS: mWeb SafariMacOS: Chrome / SafariMacOS: Desktop |
Merging even though reassure tests aren't done because:
|
@roryabraham looks like this was merged without a test passing. Please add a note explaining why this was done and remove the |
Not an emergency – see last comment |
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to staging by https://github.com/roryabraham in version: 1.4.22-0 🚀
|
🚀 Deployed to staging by https://github.com/roryabraham in version: 1.4.22-0 🚀
|
🚀 Deployed to production by https://github.com/thienlnam in version: 1.4.22-6 🚀
|
@roryabraham @hayata-suenaga @blazejkustra @fabioh8010
Details
Enable TS ESLint rules to ESLint rule to be standardize type-only imports in the codebase.
Enabled rules:
Fixed Issues
$ #32368
PROPOSAL:
Tests
This change only affects TypeScript, not JavaScript. Therefore, it has no effect on the app at runtime. The only tests that should be needed are to run
npm run typecheck
andnpm run lint
and verify that both pass.Offline tests
Not needed.
QA Steps
No QA.
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
MacOS: Desktop