Invalidation issue related to 'assembly' naming causes dependent tasks to be rebuilt then they should not.

[strobe]

Recently we got strange issue with tasks graph invalidation in ScalaJS project which caused build to took more time that is should.

After some digging I was able to reduce this case to minimal reproducible example https://github.com/american-fable/demo-mill-assembly-invalidation-issue (see README.md it has instruction how to reproduce issue).

In short for unknown reason if task has name 'assembly' it causing to invalidate dependent tasks without any changes in those tasks but if different name is used for same task it won't invalidate those as it should be.

(tested on 1.0.6-jvm)

[lefou]

This is most likely because def assemply is already defined in JavaModule which is inherited via ScalaBaseJSModule -> ScalaJSModule -> ScalaModule -> JavaModule.

So you effectively overriding it, which means the other tasks in all the inherited modules that depend on assembly need to be re-wired to your assembly task. Mill is effectively creating a dedicated task instance for each inherited task definition, so that you can do things like calling super.assembly().

If your assembly task is not meant to enhance/replace JavaModule.replace, choosing a distinct name it the right thing to do.

[strobe]

I updated example little bit to remove unnecessary calls to highlight usage pattern.

Anyway, I think while It has much sense technically but from Mill user perspective its very strange behavior because is hard to expect that small change in single module could lead to significant build process changes in unrelated base modules especially because you might not have visibility of that wiring like with 'scalablytyped' case (in that example is no direct relation between 'assembly' and scalablytyped plugin, but it's build process is affected).