I'm pretty happy with the direction Amper is going...

# amper

[SIMULATAN]

I'm pretty happy with the direction Amper is going, but am facing some difficulties using Ktor with JS.
Using this `module.yaml`:

product:
  type: lib
  platforms:
    - js

settings:
  ktor: enabled

dependencies:
  - $ktor.client.core

dependencies@js:
  - $ktor.client.js

..I encounter two issues:
1. the io.ktor:ktor-bom dependency could not be resolved for the jsPackageJson task (see the log) - may be a problem with the Ktor bom though. Hardcoding the full dependency (including the version) works just fine..
2. unfortunately, $ktor.client.js has no catalog entry. However, looking at mvnrepository.com, I can clearly find a mention of the dependency in the bom. It looks like all entries are hardcoded.. are there any plans to generate it based on the entries of the respective BOMs? Updating this massive single file for sure is quite the task..

[joffrey]

Thanks for reporting this. There are 2 rather important notes here: Kotlin/JS is not officially supported yet in Amper, and Gradle-based Amper is deprecated. Now what you reported is still quite relevant, but I just wanted to make sure you are aware of this.

1. We'll have a look at the issue with resolution of JS, but first we'll need to reproduce in standalone Amper.
2. It's important to note that catalog entries are technically unrelated to the BOM. A typical example is the $kotlin.* catalog, which is always provided even when no BOMs are involved. The BOM is about allowing to omit the versions when declaring dependencies, while the catalog is about providing a type-safe shortcut to declare dependencies without explicitly listing the coordinates. We offer additional library catalogs as convenience for users when they enable compose, ktor, or spring, to help with frequently used dependencies. We also automatically add a BOM for convenience. They play well together but don't have to be strictly aligned, so I don't believe we'll generate all of those based on the BOMs. That said, it could be an idea to augment the hardcoded catalogs with generated entries from the BOM. Thanks!

[SIMULATAN]

I see. Unfortunately, I have to use Gradle as I need some advanced features not available in Amper yet.
Regarding #2: ahh, that's quite smart! If the BOM worked (which, as said, may be a different issue alltogether), that'd "resolve" the problem of manually declaring the dependency without the version catalog. I previously wanted to avoid that as I didn't know of any variable of sorts containing the version, but if the BOM is registered in a way that our declarations can use them, that problem is mitigated as we can just omit the version. Replacing the hardcoded catalog would, of course, still be a good change to make.