Tobias Roeser

@lolgab Ah, now I think I see what you mean. I think when we use a special top level module, we should simply ignore or reject other top level tasks.

First I want to say having to explicitly declare a top level module isn't IMHO a big deal for newcomer or expert. It's only one line above and a curly...

Just to make this clear. For me, this RFC is not so much about making the build file smaller but about having a more convenient Mill cli.

> @lihaoyi My suggestion is for the supertype to be coming from the mill configuration (like the `.mill-jvm-args`) and to default to the current type that Mill root. I don't...

As a side note: I like to see Mill as having one single source of truth, the `build.sc`. (Almost) everything else is included from it. The only exceptions are the...

> I think having a top-level `object build extends FooModule{}` is an acceptable price worth paying. Having it in an external config file is definitely possible, but it kind of...

One idea is to have a `def mainModule: Module = build` (or something in that spirit) in the synthetic outer module, which represents the module which is used by Mill...

... as a consequence, other top-level `def`s would be no longer reachable.

While thinking about a solution to * https://github.com/com-lihaoyi/mill/issues/1675 I came across the using directive, which is used by Scala-cli and available as a stand-alone Java library (https://github.com/VirtusLab/using_directives), and which could...

Directly extending a given module: ```scala //> using extends "mill.scalalib.ScalaModule" override def scalaVersion = // ... ``` Extending a (local) self-defined module: This one will probably not work, as `Common`...