How does DIKTAT COMMON work

[lyharrietbui]

Hi Team,
I am trying to configure diktat with spotless and have some questions about DIKTAT COMMON. I am not sure how it is interacting with the system. I currently have it enabled as false in the diktat-analysis.yml file.

• Is it a rule that can be enabled and disabled?
• If it is disabled, what kotlin version is acceptable?
• If it is enabled, what kotlin version is acceptable?
• Does diktat run ktlint? If so, can it be configured to not run ktlint? We want the ktlint config to be controlled separately, e.g. for the excludes and the version.

# Common configuration
- name: DIKTAT_COMMON
  enabled: false
  configuration:
    # put your package name here - it will be autofixed and checked
    domainName: org.cqfn.diktat
    # testDirs: test
    # can also use chapter names here (not only numbers)
    # expected values:  disabledChapters: "Naming, Comments, General, Variables, Functions, Classes"
    # or: "1, 2, 3, 4, 5, 6"
    disabledChapters: ""
    testDirs: test
    kotlinVersion: 1.5

[petertrr]

Hi!
DIKTAT_COMMON is not a rule, it is a set of options that can be used by all other rules. Disabling or enabling it should have no effect, IIRC.
kotlinVersion is used in some rules to determine, which language features are available. Diktat accepts both minor (like 1.5) and patch version (like 1.5.31).
The most important option in DIKTAT_COMMON is domainName, as it's used for checking package naming.
Diktat doesn't run ktlint, but diktat uses ktlint core as a framework. I.e., when invoked from spotless, only diktat ruleset is loaded and executed. Ktlint core loads editorconfig, but diktat doesn't use it, it uses only yaml config.

[lyharrietbui]

Thank you!

[lyharrietbui]

@petertrr is kotlinVersion in DIKTAT_COMMON supposed to be the same kotlin version the service is using?

[petertrr]

@petertrr is kotlinVersion in DIKTAT_COMMON supposed to be the same kotlin version the service is using?

It is recommended to keep them equal, otherwise diktat could suggest using things that don't make sense in the actual version, like inline classes, which are already substituted by value classes. Usually, such language features are introduced in minor releases, not in patch ones, so its enough to keep version like 1.6 in the config file.