Easier way to lint script files

[Aleksander Brzozowski]

Hi guys, I have a project structure like this:

scripts
└── setup-something.main.kts
src
├── main
├── test
└── integration

In order to lint script files, I use such configuration:

build.gradle

tasks.named("lintKotlinMain") { source "scripts" }
tasks.named("formatKotlinMain") { source "scripts" }

I am wondering if there should be easier approach for linting additional files (scripts in this case).
Maybe a new configuration option? (based on ktlint-gradle)

kotlinter {
    kotlinScriptAdditionalPaths {
        include(fileTree("scripts/"))
    }
}

[Jeremy Mailen]

The automatically created tasks are based on sourceSets the plugin can query from gradle.
I don't know if gradle yet has an appropriate way to resolve kts files, leaving us with various options to manually specify them.

Another option would be to create a single top level custom task pair glob including all scripts in your project.

[Aleksander Brzozowski]

@jeremymailen
What do you think about new configuration option, similar to ktlint-gradle:

kotlinter {
    kotlinScriptAdditionalPaths {
        include(fileTree("scripts/"))
    }
}

?

[Jeremy Mailen]

@jeremymailen What do you think about new configuration option, similar to ktlint-gradle:

kotlinter {
    kotlinScriptAdditionalPaths {
        include(fileTree("scripts/"))
    }
}

?

How should the user interpret this configuration? Is this one script directory to lint at the top level of the project or for a multi-module project is it a directory at this path in each module?
Should it create a separate lint/format task or add the scripts to the target files for one of the existing lint/format tasks in a module -- remembering of course that a module might have multiple lint/format tasks if there are multiple source sets in that module -- main and test are standard.

There are quite a few different uses for kts files -- for example gradle build scripts, other scripts. I'd be curious to know your use case for context. Depending on the use case a task might make sense to stitch in to a different phase of the build lifecycle.

Sorry to be long winded, but to give context, let's say I have a multi-module project and I run

gradle :libs:connectors:build

I know it's going to operate on each of the source sets in connectors with a lifecycle: lint -> test -> compile -> assemble
In what phase of the build lifecycle should I lint kts scripts and in what scope?
Not knowing that, we left it up to people to create custom tasks to lint kts files and stitch those into the lifecycle where needed, but perhaps there are common enough patterns for how kts file are used that we can create some standard tasks and make them configurable enough?

[Aleksander Brzozowski]

Well, in my case, those scripts are used for:

• configuring initial state of the service,
• generating example data

We have a single module application, and we use scripts at the top level, there is no main / test directory inside scripts folder.

I know it's going to operate on each of the source sets in connectors with a lifecycle: lint -> test -> compile -> assemble
In what phase of the build lifecycle should I lint kts scripts and in what scope?

I understand your point of view - in my opinion, scripts should not be the part of compilation phase - or if we want that, we should set it explicitly.

As far as I am concerned, if we have configuration like below:

src
├── main
├── test
└── integration

The plugin will create three tasks, for each source set, like this:

• lintKotlinMain
• lintKotlinTest
• lintKotlinIntegration

(with equivalent tasks for formatting)
And, the question is - should we add additional task, like lintKotlinScripts 🤔

Now I get your point. It seems like it is better to use explicit configuration, like this:

tasks.register<LintTask>("ktLintScripts") {
    group = "verification"
    source(files("scripts"), file("build.gradle.kts"))
}

Summing up - I don't think that we should add more configuration to the plugin, I should rather use aforementioned configuration to lint script files (the same with build.gradle).

Thank you very much for the explanation! 🙂

[Jeremy Mailen]

Yeah, thanks for the extra context.

Curious if your use of scripts is part of using a framework that you've adopted? It could be there are popular frameworks that utilize kts files and it would make sense to say "kotlinter supports framework x" and automatically configure some extra tasks. Beyond that, custom tasks is probably the best option.

[Aleksander Brzozowski]

Curious if your use of scripts is part of using a framework that you've adopted?

No, it isn't 😃
Those scripts are custom ones and are executed by a developer every time he wants to do something - for example create an order in shop, add offer etc.
We've used bash scripts before for the same purposes, however after inventing kotlin scripts, we decided to give it a try, and it turned out that it is better to write those scripts in kotlin (easier syntax and error handling) 🙂