reduze VS buck2

If not: Editing the source file may lead to silent formatting jumps, which invalidate your AST. This rules out in-memory AST patching and any tracking of how the AST has been modified (you need to track AST to source locations for that). I've written about that in my another very unfinished reduction project.

There're tools which do this, for example https://bazel.build/, and https://buck2.build/ However they have a learning curve, which might be steep for some folks.

There's a new build system which works on similar ideas to buck: https://buck2.build/

Great question! Our approach has been to use Bxl (https://buck2.build/docs/developers/bxl/) to script up operations that call various subtargets like `[compilation-database]` for `cxx_library`. I don't think all these pieces are open source yet, but https://github.com/facebook/buck2/blob/main/prelude/rust/rust-analyzer/resolve_deps.bxl is a snippet that is used to drive Rust Analyzer. Bxl does seem to be the "missing piece" for mapping between what the build system wants and what the IDE wants. But there's still a bunch of work after you get there to plumb into LSP.

I don't think all these pieces are open source yet, but https://github.com/facebook/buck2/blob/main/prelude/rust/rust-analyzer/resolve_deps.bxl is a snippet that is used to drive Rust Analyzer

See https://github.com/facebook/buck2/tree/main/shim/third-party/rust/fixups for the list of fixups. I'd say it is slightly trending down, as more people stabilise around libraries such as rustix for OS-specific functionality. But I'd say that a better approach would be for Reindeer to ship a default set of fixups for most common libraries, so it was shared. We haven't tracked fixups over time.

The recent blog about Buck2 and our GitHub.

The way it's done internally (and which we think is a good way to do it) is to implement the linter in two stages. In your Buck rules, you have something that produces outputs that describe transformations that need to be done, then an external binary calls Buck2 to produce those outputs. That binary can then apply the transformations that were requested. There are some examples and a bit more discussion over here: https://github.com/facebook/buck2/issues/115 -Thomas O. What are the long term plan to manage prelude / third party rules? I.e. if there is a repository for rules typescript / ruby, how should a user go about downloading them and keeping the version up-to-date?

We have a small example project that demonstrates what that would look like with buck2: https://github.com/facebook/buck2/tree/main/examples/bootstrap

There are a few references to NixOS on the code/issues.[0] I wonder what Meta's use case is for NixOS.

[0] https://github.com/facebook/buck2/search?q=nixos&type=issues