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

Provide EditorConfigOverride API which can be defined at runtime #2190

Closed
paul-dingemans opened this issue Aug 21, 2023 · 0 comments · Fixed by #2194
Closed

Provide EditorConfigOverride API which can be defined at runtime #2190

paul-dingemans opened this issue Aug 21, 2023 · 0 comments · Fixed by #2194
Assignees
Milestone

Comments

@paul-dingemans
Copy link
Collaborator

Based on: https://kotlinlang.slack.com/archives/CKS3XG0LS/p1692379551133839

If an API consumer calls the KtlintRuleEngine it can provide an EditorConfigOverride. Currently, this EditorConfigOverride can only be defined via factory method from(vararg properties: Pair<EditorConfigProperty<*>, *>): EditorConfigOverride. The advantage from ktlint perspective is that it can be guarranteed at compile-time that the EditorConfigOverride only contains valid EditorConfigProperty. The downside of it, is that the API consumer must include the definitions of the EditorConfigProperty at compile time as well. Typically the EditorConfigProperty are defined inside rules which can be provided by different artifacts (either ktlint or provided by another rule provider).

From perspective of ktlint-gradle (and possibly also for other API consumer), it is preferred to provide the artifacts containing the EditorConfigProperty definitions only as runtime dependencies. This requires an API to build and EditorConfigOverride which is more Lazily evaluated. The signature of the factory method, could look like from(vararg properties: Pair<String, String>): EditorConfigOverride where the pair contains the name and value of a .editorconfig property.
When a Lazy EditorConfigOverride is provided to the KtlintRuleEngine, the properties provided have to be matched with properties that are used by the rules that are provided. Properties which can not be matched with a property provided by the rules can be ignored silently (but with a log warning). Properties which can be matched but have an invalid value according to the EditorConfigProperty definition will throw an exception before files are processed.

@paul-dingemans paul-dingemans added this to the 1.0 (Yeah!) milestone Aug 21, 2023
@paul-dingemans paul-dingemans self-assigned this Aug 22, 2023
paul-dingemans added a commit that referenced this issue Aug 22, 2023
…be defined with dynamically loaded rulesets

Closes #2190
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 a pull request may close this issue.

1 participant