I really enjoy being able to write `.kts` scripts ...

# scripting

[darkmoon_uk]

I really enjoy being able to write .kts scripts instead of `.sh`; keeping more complex scripts in a powerful, familiar language.

Unfortunately the usefulness of kts is unduly limited by IntelliJ IDE's failure to resolve symbols across @file:Import dependencies - this is an essential feature for composing scripts together e.g. importing some library functions from a common.kts - meanwhile the scripts still run fine, it's just IDE support that's lacking.

This problem has only become more impactful with junie Junie; as the agent sees 'unresolved' false positives and erroneously act upon them, struggling for a fix that never comes.

kodee sad This limitation is very sad, given it's been hanging for over 2 years...

KTIJ-16352 Scripts / IDE: unresolved reference when trying to import file in main.kts scripts with @Import annotation

Any insights into this issue in or outside of JB? Is scripting just abandoned beyond what's needed for Gradle? Such a shame, it's a killer feature in my book.

[mbonnin]

I have learned to put all my logic in a single file (using clikt to have different subcommands) but agree getting proper Import support would be quite important to organize scripts a bit better

[mbonnin]

I'm sure you have seen that 2024 blog post, would be quite nice to have an update. Feels like with a couple of improvements (like Import IDE support) and a bit of education, main.kts could become quite big.

[darkmoon_uk]

Thanks @mbonnin, revisiting the blog post; it seems to suggest that at least the .main.kts use-case would continue to be supported (implying that should include support for things like `Import`s in said main scripts?).

I'm in a bit of a dilemma with it now - I like your suggestion of a single Clikt based script, but at 1,700 lines on the first cut, that's getting a bit unwieldy for man or machine.

My use case is total of 5 operations that prepare AWS at an org level then orchestrate Terraform operations at an App level within the org. It's mostly invoking other tools but I wanted to add in some safety for scoping out what objects already exist in the environment - hence the increased level of logic and draw towards kts. Maybe I'll just recognise it as a full blown JVM project(!?)

...or just reluctantly go back to .sh scripts. Once again, sad that @file:Import breakage in the IDE is my nail in the coffin for kts usage. I don't have the time to dig into the IDE integration source - that'd be a whole new area for me.

[mbonnin]

it seems to suggest that at least the .main.kts use-case would continue to be supported

This is what I understand as well, despite the relatively not engaging post. I wrote a follow up there: https://mbonnin.net/2024-11-21_state-of-kotlin-scripting/

1,700 lines on the first cut, that's getting a bit unwieldy for man or machine.

At that stage, another solution is to start pulling Gradle and make it a "real" project with run JavaExec task. Sure, it's a bit more boilerplate but doesn't take that long to setup.

Don't get me wrong, I'd still love to get support for @file:Import but until this is supported, I'd rather have extra build.gradle files than going back to .sh files

[darkmoon_uk]

Yeah, as I sit here mulling it I'm leaning that way too. A small CLI project that CI compiles as an early step would be fine enough.

[darkmoon_uk]

...technically not far away from what kts would be anyway; just without its sugar.

[mbonnin]

Yea, extra src/main/kotlin and build.gradle.kts ceremony 🤷

[darkmoon_uk]

Yeah the worst part is the impact that has on other Devs who don't want to be concerned with the above mental journey ☝️

There's a qualitative difference between documenting '_go and compile this project, now invoke a JAR file buried in some output folder_', or simply '_invoke the infrastructure tool with_ ./infra.main.kts org bootstrap etc.

[darkmoon_uk]

A script to start the build and move the tool file into the current location might help... I could even make it a kts 🙃 🐢

[mbonnin]

There's a qualitative difference between saying 'go and compile this project, now invoke a JAR file buried in some output folder',

Yea... Would be really cool to have kotlinc become as ubiquitous as sh

[darkmoon_uk]

Yep that's just it, I want Kotlin to shine in its ease - and it's so close!

[darkmoon_uk]

It even works! Just not this one aspect of the IDE tooling which happens to be a deal breaker 😬.

[Piotr Krzemiński]

it still hasn't been announced properly, but: https://kotlinlang.slack.com/archives/C02UUATR7RC/p1747818821341879

[Piotr Krzemiński]

cc @Vladislav Koshkin 🙂

[Piotr Krzemiński]

looks like https://youtrack.jetbrains.com/issue/KTIJ-33496/ (got very little attention) and https://youtrack.jetbrains.com/issue/KTIJ-16352 (66 x 👍, lots of comments) aren't aware of each other

[mbonnin]

TBH, right now I'm stuck on https://youtrack.jetbrains.com/issue/KTIJ-34699/ReportingExternalDependenciesResolver.re[…]alStateException-Sequential-reporter-is-used-concurrently

[mbonnin]

I don't have any kind of autcomplete when I have DependsOn in my scripts 😞

[mbonnin]

(using K2)

[Piotr Krzemiński]

☝️ looks like a fairly recent regression? a different problem than the general support for @file:Import that is finally coming 🎉

[mbonnin]

Yes, it is. Just complaining a bit that I can't really test @file:Import just yet 😿

[mbonnin]

Is the @file:Import support in IJ EAPs already?

[Piotr Krzemiński]

yes, although partial - see https://kotlinlang.slack.com/archives/C02UUATR7RC/p1747981803122509?thread_ts=1747818821.341879&cid=C02UUATR7RC

[Vladislav Koshkin]

Hi! Yes, the feature is gonna be included in the following release (2025.2)
I'll update the ticket

[darkmoon_uk]

I literally just finished porting all my .main.kts scripts to a JVM CLI project, after giving up on scripting entirely because of this Import issue.

Now you're telling me it's fixed?

I'm happy, really 🎉 😑

(seriously though, thank you for your work @Vladislav Koshkin - this is great news for Kotlin kodee happy )

[Vladislav Koshkin]

ease the .main.kts requirement into something more standard and shorter, it deserves a transition to its own single extension

hmm could you elaborate?

[darkmoon_uk]

Pretty sure @Kaanixir means just be able to execute ./myscript.kts from command like instead of requiring that it be named .main.kts. It's a minor change but would make Kotlin Scripting feel less like it requires special treatment, and more like any other .sh invocation.

It's also an easy requirement for newcomers to miss - my own first attempts to run a kts were frustrated because I didn't realise the .main.kts naming was mandatory for an entry point.

[Piotr Krzemiński]

we could have just .kts, then I imagine the following compiler's behavior: if there's a fun main(...), treat it as an entry point (like today's .kts). If there's no fun main(...), behave like today's .main.kts . It's also an elegant way to converge to the single extension

[darkmoon_uk]

Exactly, I don't see the .main part as desirable or necessary - not sure why it was ever mandated (though I assume there was a reasoned decision made about it at some point).

[Piotr Krzemiński]

according to https://kotlinlang.slack.com/archives/C0BT46EL8/p1566469443087000?thread_ts=1566452546.071800&cid=C0BT46EL8, it was just an experiment, and is also akin to e.g. .gradle.kts (or any other custom script definition - I think that's the name) so captures some context where the code is compiled. However, the solution has matured enough to consider dropping the main part

[mbonnin]

Agree this is a big source of confusion. I can see why it was done though, because there could be other non-standalone scripts usages

[mbonnin]

Like if you do kotlin build.gradle.kts surely it's a mistake, even if it ends with .kts

[mbonnin]

But yea, removing .main would certainly be acceptable now. This is also what kscript used to do (and is still doing actually ^^)