(((•)))
tech.interfluidity.com
a notebook by steve randy waldman
→ See also top, archive, subscribe, drafts blog, interfluidity main
2023-10-09 ⇒

# Contributing to mill

I'm a big fan of Scala build tools, both `sbt` and `mill`. I've done some pretty big projects intimately based on `sbt`. Recently I spend a lot of time in `mill` because it's very well suited to static-site generators, and because I've had better success getting `mill` builds to call into Scala 3 code, as some of my site-generation tools require. I've contributed to both projects.

There are a few hints I want to give myself for when I contribute to `mill`.

## Build and run

The trick is just

    $ ./mill -i installLocal

in the mill repository. If the build succeeds, the a `mill-release` executable appears in the `target/` directory of the repository. One can test and play with that.

## scalafmt

`mill` wants code contributions to pass a `scalafmt` check before merging. You build `mill` with `mill` of course, and `mill` makes this check easy.

To check formatting...

    $ mill mill.scalalib.scalafmt.ScalafmtModule/checkFormatAll __.sources

To have `mill` go ahead and reformat your code...

    $ mill mill.scalalib.scalafmt.ScalafmtModule/reformatAll __.sources

I have now twice, embarrassingly, forgotten to do this.

## ???

I'll probably update this entry in place over time, if I find more hints I want to keep.

← Referring to Scala collections
↑↑↑
(Library + Script) vs (Application + Config File) →