I would be extremely wary of any situation where I am required to scalafix my library code on-the-fly to cross-compile it. I would never trust it enough (note that tests don’t help, since they would require the same rewritings, so I cannot trust my tests either). scalafix is great as long as I can see and review the
diff as part of my commit. I would not trust it to be an automated, invisible part of my CI.
IMO being able to cross-build the (some) same source code is critical to the viability of the new collections library. I had already expressed my concerns on this issue in some GitHub PR or issue, and in particular about the case of
.to. IMO having code that just can’t cross-compile ever is a mistake that will endanger our ecosystem.
I would also advise against deprecating stuff that cannot be written in a different way in the previous releases. In Scala.js we already have to deal with this situation for the internal compiler APIs, and we have to constantly live with deprecations in our compiler codebase, which means we cannot enable
-Xfatal-warnings, which in turn causes genuine problems to sneak in without our CI detecting it. Ideally, I would like to be able to write code that cross-compiles without any warnings on all versions. But at the very least, I must be able to write code that compiles without any warning in the newest version, and also compiles (possibly with warnings) in the old version.