@salmon-fish-51828 Sounds reasonable. Honestly, I've been lurking around this slack for quite some time (over a year, for sure), and was unwilling to take the plunge myself. Seems daunting. A lot of folks (I think, anyway) use pants next to other build tools. (I think the Foursquare blog post suggested that they first started using it just for unit tests or some such.) Personally, in retrospect, I wish I'd have dived in sooner. I had the opposite experience with SBT -- at first, I loved it, because things just magically work. The bigger the project became, and the more I learned about it, the more I grew to feel like I was fighting against it. The move away from Build.scala hurt me because my IDE stopped auto-completing stuff for me. 🙂 I tried to port that project to pants and it was hard -- too many built in SBT assumptions that required refactoring and I didn't want to shake the team with that kind of wave. I changed companies about 8 months ago, and this time, we're pants from day one, and I just build support in any time we need something. I was a python developer in a past life, and there are plenty of examples to base your code on, so I've found plugin development pretty easy so far. Regarding (3), above, pants runs zinc in a hot JVM in the background, so even though you have to re-type

/pants run ...

or

./pants compile

or whatever, it picks up where it left off quite quickly, which is fine for our vimmers. I use the IntelliJ plugin for quick feedback, and it's awesome -- compared to sticking your whole sbt monorepo into intellij, which slows it to a crawl. Regarding (4), I don't know much about scalajs, but that sounds like a code generator, which could be supported similar to pants's support for thrift, I think. But I might be wrong. 🙂