Does anyone know why `mutableListOf` would not be available in the `commonMain` namespace? This is ...

# kotlin-native

[phisch]

Does anyone know why mutableListOf would not be available in the commonMain namespace?
This is incredibly frustrating, since i think this worked earlier, and now it doesn't. Invalidated caches, restarted IDE and computer, nothing seems to help 😕

[phisch]

And then a couple minutes later the IDE doesn't complain for 1 minute, and you can jump to its definition and then it goes back to broken.😭

[andylamax]

update you kotlin ide plugin

[phisch]

it's already the latest version

[phisch]

and again, this only happens in the commonMain directory, every other directory works. also made multiple projects to test, and it's always the same

[phisch]

Here is a video that shows that this works in nativeMain, nativeTest, commonTest but not commonMain this makes no sense to me

[phisch]

also when copying the same file over to commonMain i get this popup:

[phisch]

If anyone stumbles over this, i am convinced this is a but with IntelliJ or the Kotlin plugin, and i opened an issue for it: https://youtrack.jetbrains.com/issue/IDEA-270688

[russhwolf]

What targets do you have? I think there's a known issue with commonizer having trouble if you only have a single native target and nothing else.

[phisch]

@russhwolf i have a native target (currently only linux), and a common target for the platform independent business logic. and that common target is "broken". I can just move everything to the native target and this would work, but well, that's not really a solution.

I don't mind bugs, all of this is alpha, but this is a bit more than just a small bug, how can this slip through?

[russhwolf]

I think the issue will go away if you add another platform target. You can also try disabling commonizer by removing kotlin.native.enableDependencyPropagation=false from your gradle.properties

[phisch]

Removing `kotlin.native.enableDependencyPropagation=false`from gradle.properties (and reloading the project) does not have an effect on this issue.

Adding multiple targets seems to make commonMain behave normally:

[phisch]

But having only a native target and common should be a normal use-case imo. blob shrug
Still very good to know though, thanks for that tip!

[russhwolf]

Yeah it’ll be supported better in the future (I understand there are big improvements coming in 1.5.20 and 1.5.30) but right now it happens to be a broken edge-case in the infrastructure that otherwise helps infer what APIs are available in shared source-sets

[russhwolf]

I guess another workaround is, don’t use commonMain if you only have a single target because you don’t have anything to share with anyway. That’s maybe why it’s a smaller issue than it looks like at first glance

[phisch]

I mean, i am working towards one target first, i still intend to implement multiple targets. That's why i'm extracting and testing my core business logic into common.

Even with all the bugs, Kotlin still is too much fun to stop working with... But i want the future now!

[louiscad]

Your use case makes perfect sense. It is linked to issues I had a long time ago, and an issue I witnessed today where only one target would be there.

I'll try to raise awareness on this issue so it gets addressed if 1.5.20 or 1.5.30 don't already fix that single target with common code use case.