The default project generated by <https://kmp.jetb...
# multiplatform
e
The default project generated by https://kmp.jetbrains.com/ has some minor TOML issue: it uses both kebab-case and camelCase. That looks inconsistent in the build.gradle.kts files, where you might see the following (see image), with some reverse.dot.notationWithASuddenChangeToCamelCase, but in other cases it's just reverse.dot.notation.without.uppercase.letters. The latter seems nicer to me, but I don't care much, as long as it's consistent. Now it seems inconsistent, as both are used. I wonder what I'm missing; is there a convention/standard/style for the version catalog? Here are the official docs: https://docs.gradle.org/current/userguide/platforms.html#sub:conventional-dependencies-toml . That seems to use kebab-case everywhere.
1
c
From the linked documentation: > In case you want to avoid the generation of a subgroup accessor, we recommend relying on case to differentiate. For example the aliases
groovyCore
,
groovyJson
and
groovyXml
would be mapped to the
libs.groovyCore
,
libs.groovyJson
and
libs.groovyXml
accessors respectively. > > When declaring aliases, it’s worth noting that any of the
-
,
_
and
.
characters can be used as separators, but the generated catalog will have all normalized to `.`: for example
foo-bar
as an alias is converted to
foo.bar
automatically. So, while the examples may be consistent, it appears to explicitly allow what you’re noticing.
e
Interesting. I searched for 'case' but didn't see that particular sentence. My bad! Still, that leaves the question why one would want to (un)group stuff like
groovyCore
etc. Why is that useful, when is it recommendable or even the default style to adhere to?
c
Not sure? If I’m speculating and trying to infer a reason for the choice in the default template, I’d probably notice that the behavior is different between the
[libraries]
section and the
[plugins]
section. Within
[libraries]
it’s consistently kebab and preserves the structure the library packages. Within
[plugins]
, they use case as a differentiator, which, as I describe it, seems useful?
My projects (at the moment) all use kebab across all sections, but after thinking about it here, I’d consider adopting “kebab for libraries; camelCase for plugins” as a convention, which seems like what the generator is doing?