Lorenzo Gabriele

The underlying problem described in the conversation between @jvican and @sjrd is still there. However, the particular issue with Scala.js `1.x` where `x != 0` was solved here: https://github.com/scalacenter/bloop/pull/1423 Maybe...

> @mrfyda Hi, any updates on this? I see that an internal ticket was created and was wondering if this is resolved already. We moved our issue tracking to another...

@aaronmallen Thank you for the sample code. Yes, as @mrfyda wrote, until we support SimpleCov natively, a workaround is to use either the [lcov](https://github.com/fortissimo1997/simplecov-lcov) or [Cobertura](https://github.com/dashingrocket/simplecov-cobertura) formatters.

Checked with `0.10.0-M1-5-e3e32e` and it fails.

> We could transform ivy-deps of other modules to be just "java" dependencies without any cross-version semantic. This can of course lead to issues too. > > Thinking a bit...

I find having a special object in the build as a `TopLevelModule` very confusing.. What happens if you have the same task both in the special object and in the...

But I don't see the point of having all the extra code, concepts and complexity if then users need to write the same build file but with a `with TopLevelModule`...

@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 know...

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

@lefou I don't know if the two problems are related. First of all this change is only syntactical, to make the old `ivy"a::b:c"` become `ivy"a::b:c".withPlatformed(false)` and `ivy"a::b::c"` become `ivy"a::b:c"`. Second...