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 😬.