Proposal: js/native subcommands instead of arg prefixing

[keynmol]

Problem and current state

Both Scala.js and Scala Native have a long list of supported features, which are currently encoded as --(js|native)-... flags that get progressively longer.

Managing those flags in the CLI invocations can get difficult, especially with Native linking/compilation flags.

The flags are separately named to avoid clashing, but if you are working on a pure JS or pure Native project, having to repeat --native- or --js- becomes annoying

Flags from two different platforms are meaningless when used in a single invocaiton, e.g. this is a valid command:

> scli package . -f -o package.js --js --native-linking -lm

Proposal

• Introduce scala-cli js and scala-cli native subcommands,
• remove --native-/--js- prefixes from flags when used in one of those subcommands
• finetune the set of flags, subcommands, and behaviours when used as part of js or native subcommand

Under this proposal:

JVM: scala-cli compile/package/etc.. Open question - leaving the prefixed flags as part of this for compatibility?

Native: scala-cli native compile/package/etc., flags: --linking, --compilation, --version, etc. without suffixes + various "shared" flags, such as Scala version, options, etc.

JS: scala-cli js compile/package/etc., flags: --es-module-import-map, --dom, --version, etc. without suffixes + various "shared" flags, such as Scala version, options, etc.

[Gedochao]

Closely related discussion: #1794
cc @lbialy

[lbialy]

I'm deeply interested in sorting this whole area out. The default for artifact format (bootstraped jars) leaks into docker delivery format, can't be changed to assembly and limits the usability a lot. I have some ideas around the artifact format (and artifact wrapper if necessary) x artifact delivery format (deb, rpm, docker) matrix and it's somewhat similar to what is proposed here.

[keynmol]

Worth mentioning that this applies to commands like run and compile as well - there are platform-specific flags that affect the compiler plugin behaviour even before any physical artifact is produced (compile), or if the physical artifact format is pre-selected for the user (like run).

So it's not about packaging per se - it's a general issue of platform separation, with packaging matrix being one aspect of it.

[lbialy]

Ah, but there's a problem that some of these commands are already covered by SIP and are not --power or experimental :/ @Gedochao what do you think? The option proliferation is an actual problem because of non-sensical combinations and verbosity but if we fix this is just package with subcommands it will bring inconsistency with other commands :(

Moreover, I don't think case-app supports subcommands out of the box? Does it support nested sealed traits and therefore kubectl like syntaxes (eg.: kubectl get pods, kubectl describe deployment, etc)? @alexarchambault

[Gedochao]

@lbialy let's first design how would we like to fix it and then consider whether we want the changes to affect SIP-covered commands like compile and run as well.