Generated `Res` class in root package makes IDE autocomplete/import difficult

[TheKeeperOfPie]

There's a Res.class in the root level of the jar that means the IDE prefers importing it over the module's own generated Res for Compose multiplatform resources.

I'm not sure where this is configured or if it's necessary, but it probably just needs to be scoped to nl.jacobras.humanreadable.

[jacobras]

Hi @TheKeeperOfPie , how exactly do you run into issues with this? Usually in IntelliJ, when selecting a lower suggested option, it remembers it for the next time. A screenshot would be helpful :)

I guess this comes from https://github.com/Skeptick/libres. I'm considering switching to the Compose compiler for resources, which might fix this as a side effect. But I first need to measure the impact, see https://github.com/jacobras/Human-Readable/issues/60#issuecomment-2298542273

[TheKeeperOfPie]

I'm in the middle of migrating modules to KMP, and it doesn't prompt me at all. Because Res is already accessible in root, it automatically references it without asking to disambiguate.

This is a problem when converting R.string -> Res.string, as I don't specifically choose a Res class from the autocomplete. I just do a broad replace all and let the IDE auto-import fix things up, which prefers to auto-import the already accessible Res.

Although I think I could avoid this using the IDE auto-import excludes.

[bpappin]

I'm having the same problem. I am actually rewriting the HumanReadable i need code because it's such a problem.

[bpappin]

@jacobras Your resources are not set up as per the KMP spec: https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-multiplatform-resources-setup.html

The Res class in your library is generating at the root, in the global namespace, which makes it really tough work with. You can control where it generates with this in your build file:

compose.resources {
    publicResClass = true
    packageOfResClass = "nl.jacobras.humanreadable"
    generateResClass = always
}

[jacobras]

@bpappin correct, the project doesn't use Compose Resources yet. I'll create a separate issue to link the reasons for that (i.e. what it's missing before the switch can be made).

For now, I've used what limited options Libres offers: changing the generated class name. I can't set a package, but at least I can change Res to HumanReadableRes so it's more scoped (still a public object though...).

PR #138

[jacobras]

Released as part of https://github.com/jacobras/Human-Readable/releases/tag/1.10.1

[bpappin]

I guess that will have to do. I actually had to remove it from my project, because it was causing so many issues. I'll revisit it a bit late once you've had a chance to deploy that version.

[bpappin]

Ok, i just took a look at that PR, it will not fix the issue. I recommend you reopen this ticket as not complete.

Essentially you are doing this inside the library code:

import HumanReadableRes as Res

However, that does not address the problem. The problem is that all the other code in the system, the code the developer is working on, sees the generated Res class at the root.

[TheKeeperOfPie]

No, that PR should fix it. There's no longer a Res at the root because the generated name is changed. Thanks for the change, will make it so much easier to use now.

[jacobras]

@bpappin see @TheKeeperOfPie 's comment :) Instead of Res it's now generated as HumanReadableRes, I just added the import alias to not have to change all references internally. But there's no longer an exposed Res object.

Unfortunately it's not possible to make it internal or set a package with Libres, #139 should improve it further.

Thanks for the change, will make it so much easier to use now.

Glad to hear! I didn't realise the magnitude of this issue, in my own projects using this library I somehow didn't run into it.

[bpappin]

Ahh! Ok that makes more sense. That would help.