sbt-native-packager VS sbt-native-image

once you outgrow scala-cli, you should know sbt has a lot of plugins ( some might say it's ecosystem is the only thing keeping it relevant....) like sbt-native-packager which again does the heavy lifting for you

You should use sbt-jib. (You shouldn't use sbt-native-packager either, it doesn't work well in this regard: [1], [2].)

IMO don't take any of this advice and use https://github.com/sbt/sbt-native-packager

Take a look at sbt-native-image or sbt-native-packager for building the native image.

The reason seems to be Scala 3's new encoding for lazy vals, where a reflective access to a variable called bitmap takes place. To demonstrate this, I took the http4s g8 template, set it up with Scala 3.1.0, added sbt native-image, started the nativeImageRunAgent and ran a single request against GET /joke. After stopping the server, the native-image run agent generated the reflective configs that are required for this path of execution. Comparing the generated Scala 2.13 with the Scala 3 configs, yields a bloated version for Scala 3 that contains these additional rules:

Sbt plugin: https://github.com/scalameta/sbt-native-image

IIRC, the sbt-native-image plugin can abstract that away, too: https://github.com/scalameta/sbt-native-image#nativeimagerunagent https://github.com/scalameta/sbt-native-image

Assembly, however, has some disadvantages so you may also want to look into other alternatives like sbt-native-packager. You may even want to produce a binary using sbt-native-image (which uses GraalVM under the hood) so your users do not need to install anything at all, not even a JRE.