Adrien Piquerez

It seems the problem is `jsoniter-scala-core` uses `@specialized` which is not supported by Scala 3. So the Scala 2 and Scala 3 versions of `jsoniter-scala-core` are binary incompatible: the specialized...

> but are 3.x libraries supposed to be able to read 2.13 signatures without TASTY? Yes and it is enabled by default. That's what we always do to load the...

Thank you, @ms-valerie, for your responsiveness. I'll get back to working on this PR in January. I look forward to the missing `.proto` files and libraries, but there is no...

@vidishagawas121 thank you for the revert. Unfortunately the CI fails because of formatting. Could you run `scalafmt` and push the changes?

Thanks for the report. ~~I am not yet sure if I want to add it back, but I'll think about a replacement.~~ ~~Something like this maybe:~~ ~~api/artifacts/com.goyeau/mill-scalafix?platform=mill0.11&language=2.13~~

I created https://github.com/scalacenter/scaladex/issues/1482 with a description of the complete API I would like to implement. It contains the endpoint your tool has been using.

The code that determines the order of build targets seems to be here: https://github.com/scalameta/metals/blob/ee7372d7c71d567bcceca6251fae1a808b83d208/metals/src/main/scala/scala/meta/internal/metals/BuildTargets.scala#L66-L89 So it seems JVM is preferred over JS and Scala 2 over Scala 3. There can...

> maybe its more acceptable for writing the request body? It is indeed more acceptable for writing the request body. But then I don't like that it is not symmetrical:...

We have two APIs: 1. the ujson/upickle API ```scala val response = quickRequest .post(...) .send() val json = ujson.read(response.body) ``` 2. the sttp-upickle API ```scala val response = quickRequest .post(...)...

> Maybe that's planned, but "advanced" tutorials which would cover - for example - error handling in http requests using response descriptions (asJson etc.) would make sense as well We...