3 ms·

The main page says it's for JavaScript and TypeScript codebases. Will it support other languages?

Fiahil 5y ago
Probably not, or it would become a Make competitor
tazjin 5y ago
Your best bet for monorepo building across a variety of languages is Nix. If money is no object you can also make do with Bazel.
- infamouscow 5y ago
  I think you can benefit from using Nix and Bazel together.[1] [1]: https://www.tweag.io/blog/2018-03-15-bazel-nix/ https://www.tweag.io/blog/2018-03-15-bazel-nix/
  - tazjin 5y ago
    Personally I don't think this is a good idea. Yes, you can make it work if you for some reason have to use both tools. However, both Nix and Bazel are tools that expect to "control the entire world" and whichever way you decide to layer that onion will contain some amount of pain (not to mention that both are very complex tools and you're adding significant onboarding cost by using both).
- bamazizi 5y ago
  Curious as to why "if money is no object" regarding Bazel? Where are the hidden costs? Appreciate it if you could elaborate I haven't used it before but i'm considering Bazel, Please.Build or Nix for our monorepo.
  - tazjin 5y ago
    The primary difference is that in Nix it's fairly easy to wrap arbitrary build systems, so you can inject third-party dependencies into your codebase without vendoring and adapting their build system (plus, through nixpkgs[0], the majority of all relevant software has already been wrapped). In Bazel you have to do a lot of that work yourself. Google has essentially ~unlimited manpower to do this for the things in their third_party tree, but for any other size of organisation this is not the case and people resort to all sorts of ugly hacks. Depending on your needs these different types of projects can also coexist with each other in Nix. To use an example from my work, we have a Nix-native build system for Go[1] and code using this[2] co-exists with code that just uses the standard Go build system[3]. Both methods end up being addressable on the same abstraction level, meaning that they both turn into equivalent build targets (you can see both in a full build[4] of our repo). And for what it's worth, some of the things Bazel gets extremely right (such as having a straightforward mapping from code location to build target, universal build command) are pretty easy to do in Nix (see readTree[5], magrathea[6]). [0]: https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs [1]: https://code.tvl.fyi/about/nix/buildGo https://code.tvl.fyi/about/nix/buildGo [2]: https://cs.tvl.fyi/depot/-/blob/ops/besadii/default.nix https://cs.tvl.fyi/depot/-/blob/ops/besadii/default.nix [3]: https://cs.tvl.fyi/depot/-/blob/third_party/gerrit-queue/default.nix https://cs.tvl.fyi/depot/-/blob/third_party/gerrit-queue/def... [4]: https://buildkite.com/tvl/depot/builds/13067 https://buildkite.com/tvl/depot/builds/13067 [5]: https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md [6]: https://cs.tvl.fyi/depot@f0e6d3498d6c0f905977ea9432c311b6808634c5/-/blob/tools/magrathea/mg.scm?L22-45 https://cs.tvl.fyi/depot@f0e6d3498d6c0f905977ea9432c311b6808...
  - lhorie 5y ago
    The main thing to be aware of with Bazel is its sandboxing philosophy. Instead of using the files in place, it basically creates a copy of the relevant file structure for any given build (i.e. minus the files that might exist on a given folder but be irrelevant for a build). Because of this, it generally requires strict hermeticity guarantees from everything you're doing, so many things have to be done in a "Bazel way" (i.e. there are specific ways in which you're supposed to download dependencies and there are restrictions in terms of file creation in e.g. tests that might deal w/ I/O) The way that Bazel approaches flexibility is by being programmable (via a Python-like language called Starlark). There are open source rulesets for various languages that you can use to get off the ground faster, but they are usually fairly opinionated, so if you want to deviate from the happy path, you're going to hit face first into a fairly steep learning curve about depsets, graphs, file/symlink permissions and the like. Another "weakness" of Bazel is that it's not aware of ultra granular file-to-file dependencies out of the box (e.g. how Golang imports work vs Java's), so either you have to manage dependency graphs manually or you invest in wrapper tooling like gazelle to automate some of the BUILD file generation for you.
  - qbasic_forever 5y ago
    If you're doing something new it's pretty straightforward to start with bazel and do everything from the start 'the bazel way'. If you're pulling in an existing codebase and a lot of dependencies along with it, you could be spending a lot of time to make it work 'the bazel way'. There's a very narrow path that bazel forces you to be on--this is what makes it work so well but make it difficult to stray off that path.
- leerob 5y ago
  From what I've seen, Nix[1] is exciting and has some innovative ideas, some of which we're learning from with Turborepo. I believe Replit uses it[2]. [1]: https://nixos.org/ https://nixos.org/ [2]: https://docs.replit.com/programming-ide/getting-started-nix https://docs.replit.com/programming-ide/getting-started-nix
lhorie 5y ago
From what I've seen, the scope of this project is to compete directly against the likes of Rush and Lerna. I spoke to the creator last year and my impression was that general language support akin to Bazel's was not a primary/immediate goal.
leerob 5y ago
We're discussing more native support for other languages. It would likely be a commitment to a small subset of popular languages (e.g. Rust, Go, C++, Python) while still maintaining our goal of nearly zero configuration. https://news.ycombinator.com/item?id=30959607 https://news.ycombinator.com/item?id=30959607

Probably not, or it would become a Make competitor

Your best bet for monorepo building across a variety of languages is Nix. If money is no object you can also make do with Bazel.

infamouscow 5y ago
I think you can benefit from using Nix and Bazel together.[1] [1]: https://www.tweag.io/blog/2018-03-15-bazel-nix/ https://www.tweag.io/blog/2018-03-15-bazel-nix/
- tazjin 5y ago
  Personally I don't think this is a good idea. Yes, you can make it work if you for some reason have to use both tools. However, both Nix and Bazel are tools that expect to "control the entire world" and whichever way you decide to layer that onion will contain some amount of pain (not to mention that both are very complex tools and you're adding significant onboarding cost by using both).
bamazizi 5y ago
Curious as to why "if money is no object" regarding Bazel? Where are the hidden costs? Appreciate it if you could elaborate I haven't used it before but i'm considering Bazel, Please.Build or Nix for our monorepo.
- tazjin 5y ago
  The primary difference is that in Nix it's fairly easy to wrap arbitrary build systems, so you can inject third-party dependencies into your codebase without vendoring and adapting their build system (plus, through nixpkgs[0], the majority of all relevant software has already been wrapped). In Bazel you have to do a lot of that work yourself. Google has essentially ~unlimited manpower to do this for the things in their third_party tree, but for any other size of organisation this is not the case and people resort to all sorts of ugly hacks. Depending on your needs these different types of projects can also coexist with each other in Nix. To use an example from my work, we have a Nix-native build system for Go[1] and code using this[2] co-exists with code that just uses the standard Go build system[3]. Both methods end up being addressable on the same abstraction level, meaning that they both turn into equivalent build targets (you can see both in a full build[4] of our repo). And for what it's worth, some of the things Bazel gets extremely right (such as having a straightforward mapping from code location to build target, universal build command) are pretty easy to do in Nix (see readTree[5], magrathea[6]). [0]: https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs [1]: https://code.tvl.fyi/about/nix/buildGo https://code.tvl.fyi/about/nix/buildGo [2]: https://cs.tvl.fyi/depot/-/blob/ops/besadii/default.nix https://cs.tvl.fyi/depot/-/blob/ops/besadii/default.nix [3]: https://cs.tvl.fyi/depot/-/blob/third_party/gerrit-queue/default.nix https://cs.tvl.fyi/depot/-/blob/third_party/gerrit-queue/def... [4]: https://buildkite.com/tvl/depot/builds/13067 https://buildkite.com/tvl/depot/builds/13067 [5]: https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md [6]: https://cs.tvl.fyi/depot@f0e6d3498d6c0f905977ea9432c311b6808634c5/-/blob/tools/magrathea/mg.scm?L22-45 https://cs.tvl.fyi/depot@f0e6d3498d6c0f905977ea9432c311b6808...
- lhorie 5y ago
  The main thing to be aware of with Bazel is its sandboxing philosophy. Instead of using the files in place, it basically creates a copy of the relevant file structure for any given build (i.e. minus the files that might exist on a given folder but be irrelevant for a build). Because of this, it generally requires strict hermeticity guarantees from everything you're doing, so many things have to be done in a "Bazel way" (i.e. there are specific ways in which you're supposed to download dependencies and there are restrictions in terms of file creation in e.g. tests that might deal w/ I/O) The way that Bazel approaches flexibility is by being programmable (via a Python-like language called Starlark). There are open source rulesets for various languages that you can use to get off the ground faster, but they are usually fairly opinionated, so if you want to deviate from the happy path, you're going to hit face first into a fairly steep learning curve about depsets, graphs, file/symlink permissions and the like. Another "weakness" of Bazel is that it's not aware of ultra granular file-to-file dependencies out of the box (e.g. how Golang imports work vs Java's), so either you have to manage dependency graphs manually or you invest in wrapper tooling like gazelle to automate some of the BUILD file generation for you.
- qbasic_forever 5y ago
  If you're doing something new it's pretty straightforward to start with bazel and do everything from the start 'the bazel way'. If you're pulling in an existing codebase and a lot of dependencies along with it, you could be spending a lot of time to make it work 'the bazel way'. There's a very narrow path that bazel forces you to be on--this is what makes it work so well but make it difficult to stray off that path.
leerob 5y ago
From what I've seen, Nix[1] is exciting and has some innovative ideas, some of which we're learning from with Turborepo. I believe Replit uses it[2]. [1]: https://nixos.org/ https://nixos.org/ [2]: https://docs.replit.com/programming-ide/getting-started-nix https://docs.replit.com/programming-ide/getting-started-nix

lhorie 5y ago

From what I've seen, the scope of this project is to compete directly against the likes of Rush and Lerna. I spoke to the creator last year and my impression was that general language support akin to Bazel's was not a primary/immediate goal.

leerob 5y ago

We're discussing more native support for other languages. It would likely be a commitment to a small subset of popular languages (e.g. Rust, Go, C++, Python) while still maintaining our goal of nearly zero configuration. https://news.ycombinator.com/item?id=30959607 https://news.ycombinator.com/item?id=30959607