Tobias Roeser

This is not an issue anymore since Mill 0.10.0-M5. I also tested all Mill 0.10.x versions from `x = 0..8`.

Closing due to inactivity and conflicts. Also, the feature might be implemented in the meantime. Have a look at: * #2126

Closing this, as I think we have meanwhile a pretty robust handling of the compiler bridge. Please comment, if you think there are still cases where we miss an opportunity...

Closing this due to inactivity and conflicts. If you plan the continue it, please comment or just create a new PR.

I think, you need to add a working dir parameter to `ScalaJSWorker.run` method and plumb it into the right tools invocations in the implementation. Once, that is done, all usages...

> I started writing a longer comment but tldr this requires a breaking change to scalajs-js-envs. Can you elaborate on this? Why needs it a change in an upstream dependency?...

> > Can you elaborate on this? Why needs it a change in an upstream dependency? This issue is about defining the working (or start) directory of the node.js process....

> There are at least two options how Mill could report the exact artifactId in the above `DependencyModule`: > > 1. Change the `name` field such that includes the exact...

@fthomas Can you test against Mill `0.11.0-M3` or the latest `main` branch? In `0.11` we change how we handle transitive dependencies and resolve platform and Scala versions earlier, so there...

> Actually hold on. Running this will `mill foo.fix` doesn't actually apply the patch, but running it with Metals does. I wonder why there is a difference there. This might...