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

Upgrade ktlint support #595

Closed
wants to merge 6 commits into from
Closed

Upgrade ktlint support #595

wants to merge 6 commits into from

Conversation

fthouraud
Copy link

Hi 👋

This MR is an attempt on upgrading support of Ktlint up to 0.46.1 (#589).

I started to work on this before this MR #593 arrived. So I opened a new one anyway at least to provide help.

I've split my work into steps in order to test each version from 0.42.1 to 0.46.1.

I also upgraded Gradle to 7.4.2 and Kotlin to 1.6.21.

Comment on lines 34 to 42
private val androidProperty = UsesEditorConfigProperties.EditorConfigProperty(
type = PropertyType.LowerCasingPropertyType(
"android",
"A boolean value indicating that the project is an Android one.",
PropertyType.PropertyValueParser.IDENTITY_VALUE_PARSER,
emptySet()
),
defaultValue = "false"
)
Copy link
Owner

Choose a reason for hiding this comment

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

Can't this be inferred?

Copy link
Author

Choose a reason for hiding this comment

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

It seemed to me you were treating this property as a String but it seems feasible to be "inferred" when looking at how the indentSize property is handled in the ktlint API.

I can give it a try.

@@ -12,10 +12,10 @@ import kotlin.streams.asStream

object TestVersions {
const val minSupportedGradleVersion = KtlintBasePlugin.LOWEST_SUPPORTED_GRADLE_VERSION
const val maxSupportedGradleVersion = "7.1.1"
const val maxSupportedGradleVersion = "7.4.2"
Copy link
Owner

Choose a reason for hiding this comment

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

We like keeping the same version range support as the Google android plugin in general. Is this still kept with this change?

Copy link
Author

@fthouraud fthouraud Jul 5, 2022

Choose a reason for hiding this comment

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

If we're on the same page, the latest Android Gradle plugin version is 7.2 which supports Gradle 7.3.3 and onwards (source). Do you want me to lower the version to 7.3.3?

Copy link
Owner

Choose a reason for hiding this comment

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

Support as high as possible. But make sure we're not loosing versions still supported by the AGP

scana added a commit to scana/ktlint-gradle that referenced this pull request Jul 7, 2022
@scana scana mentioned this pull request Jul 7, 2022
4 tasks
@fthouraud
Copy link
Author

@JLLeitschuh how do you see the Ktlint support of this plugin? As is, it only supports the 0.46.1 due to the breaking changes.

If you still want to support the full range of versions from 0.34.0 then I think there should be a module for all versions prior to 0.46.1 and a second one for all versions from 0.46.1. The current plugin module could handle all common work which does not require references to a Ktlint that has been broken. This is a tremendous amount of work but doable I think.

IMHO, I think the support for the older versions could be dropped with a new major release of this plugin. Ktlint is a quality tool that should not harm any project by upgrading it. Moreover, it is configurable so that any new rule could be disabled.

What's your opinion on this?

@JLLeitschuh
Copy link
Owner

I guess one solution is to simply say that if someone requires backwards compatibility, they are welcome to contribute it.

Under that pretense, please be sure to clearly document that this will be a breaking change and move forward with the change 🙂

@fthouraud
Copy link
Author

I apologize for the delay, I got an increased amount of work lately so I'm lacking time on this.

I updated the PR with a new minimal supported version to 0.45.2. I've had to drop the 0.45.1 due to the lack of EditorConfigOverrides.

I also stepped back on the main property deprecation (JavaExecTask#main) as this would mean dropping the support for Gradle 6.0 but I think there's still time before the 8.0.

@JLLeitschuh
Copy link
Owner

I believe that this is now outdated by #597, correct?

1 similar comment
@JLLeitschuh
Copy link
Owner

I believe that this is now outdated by #597, correct?

@G00fY2
Copy link

G00fY2 commented Aug 25, 2022

@JLLeitschuh I don't get the point of the 11.0.0 release (which contains #597).:monocle_face: This only bumped Kotlin and Gradle. I thought the goal was to make ktlint-gradle ready for ktlint 0.46.+ (which this PR does)?

Maybe I am missing something?

@fthouraud
Copy link
Author

I'll give this a look during the week-end. I should be able to rebase it.

That's progress anyway. Thanks.

@G00fY2
Copy link

G00fY2 commented Aug 25, 2022

Maybe you can even check whether ktlint 0.47.0 works with your changes. ♥️

@fthouraud
Copy link
Author

I've managed to rebase this PR without trouble.

Regarding the upgrade to Ktlint 0.47.0, it will require more work than expected.

First, the RuleProvider interface is now deprecated and marked for deletion on 0.48.0. Its replacement, RuleProviderV2, is loadable using the same way (i.e. ServiceLoader). It's not very difficult to change that. I don't think it is reasonable to provide support for the old RuleProvider due to its imminent deletion.

The second change concerns the Baseline class which has been moved and refactored a bit. Nothing really difficult here.

Last, the generation of IDEA configuration is no longer provided by Ktlint. It is up to this plugin to also drop the support or to implement it directly.

I had some other failing tests I didn't look at closely but I don't think there are other significant issues.

I'll be glad to continue the upgrade process but I think this could be done in a separate MR due to the new changes it involves.

Please let me know what's your opinion on that.

@scottkennedy
Copy link

I've managed to rebase this PR without trouble.

Regarding the upgrade to Ktlint 0.47.0, it will require more work than expected.

First, the RuleProvider interface is now deprecated and marked for deletion on 0.48.0. Its replacement, RuleProviderV2, is loadable using the same way (i.e. ServiceLoader). It's not very difficult to change that. I don't think it is reasonable to provide support for the old RuleProvider due to its imminent deletion.

The second change concerns the Baseline class which has been moved and refactored a bit. Nothing really difficult here.

Last, the generation of IDEA configuration is no longer provided by Ktlint. It is up to this plugin to also drop the support or to implement it directly.

I had some other failing tests I didn't look at closely but I don't think there are other significant issues.

I'll be glad to continue the upgrade process but I think this could be done in a separate MR due to the new changes it involves.

Please let me know what's your opinion on that.

I'm certainly in favor of this. Thanks for your effort.

@jzbrooks
Copy link

jzbrooks commented Sep 7, 2022

It is up to this plugin to also drop the support or to implement it directly.

Dropping support in parity with the ktlint version seems reasonable. Especially if the major version was revised again and the minimum supported ktlint version was set to 0.47 (or perhaps 0.48 by the time this is merged). It would be a big, breaking change—but reducing the maintenance cost of this plugin seems valuable until it can get some new maintainers onboard.

There's also an argument to be made that IntelliJ should be responsible for its own configuration, so the kotlin plugin could provide an "official" and "android official" style preset, which would obviate the need for the ktlint/ktlint-gradle implementation.

Here's the relevant rationale upstream: pinterest/ktlint/issues/701

@dev-weiqi
Copy link

Any update on this PR?
Compose Rules requires ktlint versions over 0.46.0 🥲

@davidburstrom
Copy link

You might want to do something similar to diffplug/spotless#1303 to ensure it's easy to maintain support for multiple versions of KtLint.

@wakingrufus
Copy link
Collaborator

I think we can close this PR, since I have added support for newer versions of ktlint in a way that is backward compatible via reflection

@fthouraud fthouraud closed this Feb 8, 2023
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.

8 participants