Introduce mandatoryScalacOptions to keep system scalacOptions

[lolgab]

It's easy to override scalacOptions in a Scala.js + Scala 3 module.
When you do so, the compiler silently fails to compile Scala.js files.
This is a source of errors for Mill users that can be mitigated by
defining a separate list of compile options which is used internally
to add these mandatory flags.

[lefou]

I agree this is a very useful new setting/target. Yet, I don't like the chosen name. The suffix "internal" doesn't transport any meaning or purpose. Can you elaborate. Something like "platformScalacOptions" came to my mind, but I'm very open for better suggestions.

[lolgab]

I used internalScalacOptions in the sense that they are Mill internal options that users don't need / shouldn't touch (they are still protected so users can change them if they have good reasons to do so).
If we call them platformScalacOptions then they can't be reused in plugins or other scopes to define scalacOptions that people should not change otherwise things break if you remove them. ( I'm imagining Scalafix specific scalacOptions, foo specific scalacOptions or things like that ).

[lefou]

The allScalacOptions is nice. It also aligns with e.g. allSources.

I still struggle with the name. What about mandatoryScalacOptions. It reflects it own current scaladoc and tells it's purpose.

[lolgab]

The allScalacOptions is nice. It also aligns with e.g. allSources.

Cool! Also cool that it aligns since I didn't think about allSources 😄

I still struggle with the name. What about mandatoryScalacOptions. It reflects it own current scaladoc and tells it's purpose.

I like it! Going to change it to mandatoryScalacOptions.

[lolgab]

I am now thinking, what if we change scalacOptions visibility to protected?
We are already breaking binary compatibility for 0.10 and consumers should now use allScalacOptions to read the options.
The only components that need to see scalacOptions are subclasses to override them, so protected seems the perfect visibility.
@lefou Let me know if I'm missing something.

[lefou]

Only some minor text suggestions.

[lefou]

I am now thinking, what if we change scalacOptions visibility to protected?
We are already breaking binary compatibility for 0.10 and consumers should now use allScalacOptions to read the options.
The only components that need to see scalacOptions are subclasses to override them, so protected seems the perfect visibility.
@lefou Let me know if I'm missing something.

I don't think this is a good idea. Although we're designing an API here, we also try to build a convenient build tool, and in such a scenario pragmatic solutions are in most cases preferred over lengthy and well-constructed code. You never know how this is going to be used. E.g. if I'm going to need the same options in another module and some visibility prohibits it that would be rather inconvenient. I don't see any big issues with having the scalacOptions public. It's in mills concept, that some targets present some rather intermediate or detailed interim results. You don't want to save some user from using it by restricting it for all. Take the sources vs. allSources as another example. There are perfect reasons in a real project build, to access both from the outside.
And if this is not enough: being public means I can invoke and also debug (via show) the target from the command line (or a tool).

[lolgab]

And if this is not enough: being public means I can invoke and also debug (via show) the target from the command line (or a tool).

This alone is already a more than legit reason to leave it public. I imagine users that are used to check this value from the command line and then, subtlety, can't.
Thank you for the thorough reasoning :)

[lefou]

@lolgab Thank you!