-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Updated dependencies for v2022.1 #4883
Updated dependencies for v2022.1 #4883
Conversation
430b1e8
to
9b9e65f
Compare
.editorconfig
Outdated
@@ -0,0 +1,2 @@ | |||
[*.{kt,kts}] | |||
disabled_rules=import-ordering |
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 disabled checking import ordering because it has always been kind of annoying especially that in Android Studio we don't have any easy way to reorder imports so that ktlint is satisfied. And now with new updates they changed something and I was asked to change the order of menu imports despite the fact everything was fine before.
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.
Is there no way to fix using "Import layout" in Android Studio > Preferences > Editor > Code Style > Kotlin? It would be nice to keep ordering enforced, so we don't end up causing accidental changes in files using "optimize imports".
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.
Ok I downgraded ktlint because they might have something broken regarding the ordering of imports in the newest version if what we have on master is no longer accepted. I even tried different settings like:
ij_kotlin_imports_layout=* # alphabetical with capital letters before lower case letters (e.g. Z before a), no blank lines
ij_kotlin_imports_layout=*,java.**,javax.**,kotlin.**,^ # default IntelliJ IDEA style, same as alphabetical, but with "java", "javax", "kotlin" and alias imports in the end of the imports list
to no avail so let's check it after next release.
@@ -25,12 +25,10 @@ class FormMetadataTest { | |||
fun startGeopoint_withCachedFormDefinition_doesNotCauseError() { | |||
rule.startAtMainMenu() | |||
.copyForm("start-geopoint.xml") | |||
|
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.
They just decided we shouldn't use blank lines like that pinterest/ktlint#1248
I could disable the rule but it would also mean disabling checking blank lines in all the other cases (that I like).
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 feel pretty strongly about keeping those blank lines. In a lot of case it might not make sense, but I do think it helps readability in our UI tests when related groups are broken up by a blank line like that. Can we put ignore the rule and revert related changes?
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.
No because the rule is no-consecutive-blank-lines
so as I said if you disable it you disable checking all the other cases where having blank lines is obviously a bad thing.
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.
Sorry what I mean is that I'd be happy to just disable that rule. I feel like the blank lines are useful enough in some places to make up for other places they might appear and not look quite right.
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.
Are you sure? I'm going to repeat: if we do that you can add multiple blank lines in many different ways in the codebase and it won't be detected. I didn't want to do that because in all the other cases detecting blank lines worked well.
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.
Ah, you mean it's not just for chains? Sorry you're right I'm misunderstanding and that it's not worth disabling.
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's not just for chains?
yeah it's a broader rule.
You know what? now as I downgraded ktlint because of that problem with imports (see above) I can bring those lines back too. So maybe let's do that for now and complain about that in their repo (and ask if we can disable this particular check somehow if they are unwavering). What do you think?
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.
Yeah, agreed! It does seem a little broken as a line followed by a comment shouldn't count as "consecutive" blank lines. I can post a reply (seeing as I seem to care so much 😆).
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.
Ok I reverted that commit.
@@ -97,7 +97,7 @@ object Dependencies { | |||
const val hamcrest = "org.hamcrest:hamcrest:2.2" | |||
const val powermock_module_junit4 = "org.powermock:powermock-module-junit4:2.0.9" | |||
const val powermock_api_mockito2 = "org.powermock:powermock-api-mockito2:2.0.9" | |||
const val robolectric = "org.robolectric:robolectric:4.6.1" |
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 had to downgrade robolectric for now because of this issue robolectric/robolectric#6593 there is a workaround there but I don't like it so I prefer waiting for a better version of this dependency.
build.gradle
Outdated
@@ -15,7 +15,7 @@ buildscript { | |||
|
|||
dependencies { | |||
classpath 'com.android.tools.build:gradle:7.0.3' | |||
classpath 'com.google.gms:google-services:4.3.10' |
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.
The updated broke lint throwing hundreds Unused resource
errors so I downgraded for now.
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.
Let's pull out a separate issue for this.
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 usually don't file new issues for every dependency that I need to skip during upgrading. Usually if there is something wrong next time it works fine. If during next code freeze the same issue occurs then I will do that.
This reverts commit 8fd2de5.
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.
Good to merge once we unfreeze!
7be5fc6
to
a457cec
Compare
I've added (or actually removed :)) some more stuff:
|
What has been done to verify that this works as intended?
I've run automated tests.
Why is this the best possible solution? Were any other approaches considered?
This is what we do after every release.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
It doesn't require testing.
Do we need any specific form for testing your changes? If so, please attach one.
No.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:
./gradlew checkAll
and confirmed all checks still pass OR confirm CircleCI build passes and run./gradlew connectedDebugAndroidTest
locally.