Looking for some general guidance on new language plugin development. Right now, I'm adding linters/formatters to a couple of the languages I develop in, so I can monorepo and basically run the same sets of commands on pre-commit and CI for most/all of my repos, and not really think more about it. Giant win with some of my projects, neutral on others. However, after that, I'll be testing out compilation checks ("does this PR compile?") - which is where my question comes in. While it's possible to aggregate all files independently, and compile them, if there is a language with a primary mechanism for handling files/dependencies (think

Package.swift

in swift or

package.json

with Node stuff), should those be pulled in and used as a compilation target in lieu of bundling all sources? I'm not sure if a Slack thread is even the best mechanism for this, as it almost feels like a Pants "evolution" type of question. I'm kinda caught between the two cases, since I don't like duplicating work, but I see the value in going all native Pants too, but, then I think about overreach - and it all spirals in my brain. To clear up something/anything, what I'm trying to describe would be the difference between the following (noting that in both cases, the entire folder and subfolders would be pulled into a hermetic environ): a)

swift build

in a folder with a

Package.swift

which then references the sources/tests b)

swiftc Sources/File1.swift Sources/File2.swift

in the "manual" version which would have a

swift_sources

target

I think once you enter Pants into the equation, it takes over. IMO trying to hobble together pants pretending to be the other tool, you'll just get the worst of both worlds. You'll likely enter a world where pants isn't able to offer it's bread and butter, or devs have a lot of duplication. I think when pants has editor support you'll be feeling less like you might want to straddle other systems

I’d say depends on the language. Using Go as an example, Pants doesn’t invoke

go build

— it actually invokes

go tool compile

and

go tool link

so Pants can control the compilation precisely and capture the package archives produced.

Hmm, good points all around - Josh and I talked a bit about this. I'm thinking about things like migration and interop (depending on a variety of scenarios), and just the natural fact that there will end up being duplication. I do concede that calling the top-level build commands does just reduce down to a glorified shell script, though