Ideas how to avoid coditional tasks with ScalaJS: fullLinkJS, fastLinkJS.

[strobe]

Because mill statically building task dependencies graph, conditional code like this means that both tasks will be executed before current one (if condition can't be known beforehand).

if optimized() then fullLinkJS() else fastLinkJS() 

And it lot of cases is possible to deal with that by implementing something like selectTaks() which should be executed instead of that expression with conditional value known at compilation time.
That by itself fascinating issue to deal with it if for your case you can't know condition at compile time and only can get it during build like if some application returning it).

But I'd like to discuss case with ScalaJS because with it it seems easy to hit need for it while it could be avoided.

I noticed that difference between fullLinkJS, fastLinkJS it just how it pass parameters to linkTask in implementation.

mill/libs/scalajslib/src/mill/scalajslib/ScalaJSModule.scala

Line 112 in c0f5259

linkTask(isFullLinkJS = false, forceOutJs = false)()

So if something like linkJS(isFullLinkJS = false|true) could be added then is no need to conditionally deal with ScalaJS compilation anymore for lot of user cases. As it will be possible to pass value directly to it.

Is it any other way to deal with that? I think currently is not possible to override linkTask for ScalaJSModule

---

see example here at branch linker-conditions-demo https://github.com/american-fable/demo-mill-assembly-invalidation-issue/tree/linker-conditions-demo

[malcolmredheron]

I work with Strobe and want to make a second plea for this :-)

The problem:

• In my experience, it's common to conditionally call fullLinkJS or fastLinkJS depending on whether we are doing an optimized build
• However, we do extra processing on the results of the full/fast link, so having separate full/fast versions of these later steps requires duplicating code or extra complexity

Instead:

• If we could call a generic linkJS task and pass an argument to indicate whether we want a full or fast link, everything would be really simple

Would you consider a PR for this if we make one?

[lefou]

Thing is, there is currently no cacheable task-type in Mill that can have parameters, unless you count a dedecated cross-module with a single task in. Looks like my proposal for parametrized tasks would be a good fit for it.

[lihaoyi]

@malcolmredheron As @lefou said, we don't have cached parametrized tasks right now. Right now your options are:

• Use module traits or cross-modules to duplicate the task graph, once for fullOpt once for fastOpt
• Make a def myLinkJS = if (sys.props("blah")) fastLinkJS else fullLinkJS, and call Mill that with the appropriate -D flag to enable or disable it

PRs are great but what you're asking for would be a pretty deep and fundamental change in Mill that I wouldn't expect someone to be able to accomplish easily

[malcolmredheron]

Oh! We weren't thinking of anything as grand as you two are talking about :-)

If ScalaJSModule.linkTask (

mill/libs/scalajslib/src/mill/scalajslib/ScalaJSModule.scala

Line 119 in deb5d01

private def linkTask(isFullLinkJS: Boolean, forceOutJs: Boolean): Task[Report] = Task.Anon {

) were public and we called it from our own persistent task, wouldn't that allow us to indicate whether we want a full or fast link and still get caching?

[lefou]

What you describe already exists and is public. There is fastLinkJS and fullLinkJS, both cached and both using linkTask as their shared implementation detail.

If you want a cached non-parametrized task that can decide to either use fastLinkJS or fullLinkJS, you need to make the condition static or you end up with task dependencies to both tasks. This is the initial discussion topic, isn't it? We're now full circle.

[strobe]

I think I got that you mean, if linkTask would be exposed directly it won't be cached task anymore because is Task.Anon so usage of it won't be same as fastLinkJS and fullLinkJS. In that case best bet is parametrized tasks.

For now in our project we solved that via having conditions as static but overall we are not happy with solution that we got because as result lot of unnecessary complexity introduced to archive that. For example we been forced to construct some artificial tasks dependencies graph to be sure that rebuild happen in some specific situations like recompiling and restarting app if some environment variables edited.

Anyway, need in ScalaJS projects to deal with fastLinkJS/fullLinkJS pretty common, maybe something could be added specificity in ScalaJS module in order to make live of newcomers easier. It could some warning about need for using static conditions when single task depends on both..

[malcolmredheron]

What you describe already exists and is public. There is fastLinkJS and fullLinkJS, both cached and both using linkTask as their shared implementation detail.

If you want a cached non-parametrized task that can decide to either use fastLinkJS or fullLinkJS, you need to make the condition static or you end up with task dependencies to both tasks. This is the initial discussion topic, isn't it? We're now full circle.

I'm sorry. I still don't understand. If linkTask were public then I think that I could use:

  def flexLink = Task(persistent = true) {
    val full = // Somehow determine this from the environment
    linkTask(isFullLinkJS = full, forceOutJs = false)
  }

The caching would be done for flexLink, just as today it's done for fullLink and fastLink. What's wrong with this plan?

[lefou]

The "somehow" is the issue here. Your snippet will only compile when full is statically known. Meaning, it's determined when the task graph is assembled. That also means, it can't be the output of another task. That makes it more or less equivalent to the initial snippet.