-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
Hi HN!
I have been doing over month long of research in terms of figuring out the best way to manage a growing monorepo. We are trying to consolidate much of our frontend code base into a monorepo, managed by pnpm workspaces, to consolidate dependency management and take advantage of tool (as well as other code sharing benefits) of monorepos that are a good fit for us.
To that end, I'm looking to understand if anyone has used Bazel extensively for managing monorepos.
I want to understand how easy it is to configure Bazel, how easy it is to use Bazel, especially newer developers (particularly self discovery of the toolset), how easy it is to maintain it, and how much burden the tool has placed on developers. We really are looking for a tool that is largely self sufficient for the purpose.
Main features we care about:
- Maintainability: is it is to maintain (updates etc)
- Extensibility: how extensible is it? more importantly, how easily can it be extended?
- Built in watch mode that understands its dependency graph for each task, and can run them simultaneously
- Works with pnpm / npm workspaces natively
- Stream based output: e.g. if running multiple tasks it interleaves them appropriately, even better if they're labeled and color coded
- Dependency graph tracking. IE: if I run build for a package, it understands that it may have dependencies that need to be built first.
- Able to run tasks arbitrarily on a "per package" process, potentially
Now, after mentioning all that, I realize, by reading the docs, in theory Bazel supports all this and has lots of feature headroom for growing features over time which I like, however, I've read mixed things about it, but not all of the sources I've read so far are "up to date" (some articles about people adopting Bazel are years old now) and I wanted to get a more accurate picture of what is going on here.
Alternatively, I'm open minded to looking at a different set of tools
For context I've done alot of research and experimentation with the follow:
- nx[0]
- rush[1]
- wireit[2]
- turbo[3]
We've settled on, for now `wireit` in part because it has a really good watch mode feature that `nx` does not (nx doesn't have a built in watch mode for your task runner, it relies on the plugin / script to handle it, which was really problematic). However, wireit isn't extensible, and I'm not looking to have to manage sub task "phasing" with something like `gulp`. This was an issue with rushjs as well (but rushjs has its own challenges and opinions). While rush is starting to expose a direct `rush-sdk` API, its not really documented and I'm not sure about its stability or best way to go about making rush plugins. They also have a competing task runner called `heft` that I'm not sure about in the light of the `rush-sdk` and its use cases (if someone from the rush team sees this and can clarify about the long term vision and where they're at with it now, I'm all ears)
tl;dr: I've tried tons of tools, and Bazel seems to check all the boxes, but I'm afraid the complexity will kill us, since we don't have a dedicated tool engineer to oversee it, it has to malleable enough that we can maintain it bit by bit over time
[0]: https://nx.dev/
[1]: https://rushjs.io/
[2]: https://github.com/google/wireit
[3]: https://turborepo.org/docs
Hi HN!
I have been doing over month long of research in terms of figuring out the best way to manage a growing monorepo. We are trying to consolidate much of our frontend code base into a monorepo, managed by pnpm workspaces, to consolidate dependency management and take advantage of tool (as well as other code sharing benefits) of monorepos that are a good fit for us.
To that end, I'm looking to understand if anyone has used Bazel extensively for managing monorepos.
I want to understand how easy it is to configure Bazel, how easy it is to use Bazel, especially newer developers (particularly self discovery of the toolset), how easy it is to maintain it, and how much burden the tool has placed on developers. We really are looking for a tool that is largely self sufficient for the purpose.
Main features we care about:
- Maintainability: is it is to maintain (updates etc)
- Extensibility: how extensible is it? more importantly, how easily can it be extended?
- Built in watch mode that understands its dependency graph for each task, and can run them simultaneously
- Works with pnpm / npm workspaces natively
- Stream based output: e.g. if running multiple tasks it interleaves them appropriately, even better if they're labeled and color coded
- Dependency graph tracking. IE: if I run build for a package, it understands that it may have dependencies that need to be built first.
- Able to run tasks arbitrarily on a "per package" process, potentially
Now, after mentioning all that, I realize, by reading the docs, in theory Bazel supports all this and has lots of feature headroom for growing features over time which I like, however, I've read mixed things about it, but not all of the sources I've read so far are "up to date" (some articles about people adopting Bazel are years old now) and I wanted to get a more accurate picture of what is going on here.
Alternatively, I'm open minded to looking at a different set of tools
For context I've done alot of research and experimentation with the follow:
- nx[0]
- rush[1]
- wireit[2]
- turbo[3]
We've settled on, for now `wireit` in part because it has a really good watch mode feature that `nx` does not (nx doesn't have a built in watch mode for your task runner, it relies on the plugin / script to handle it, which was really problematic). However, wireit isn't extensible, and I'm not looking to have to manage sub task "phasing" with something like `gulp`. This was an issue with rushjs as well (but rushjs has its own challenges and opinions). While rush is starting to expose a direct `rush-sdk` API, its not really documented and I'm not sure about its stability or best way to go about making rush plugins. They also have a competing task runner called `heft` that I'm not sure about in the light of the `rush-sdk` and its use cases (if someone from the rush team sees this and can clarify about the long term vision and where they're at with it now, I'm all ears)
tl;dr: I've tried tons of tools, and Bazel seems to check all the boxes, but I'm afraid the complexity will kill us, since we don't have a dedicated tool engineer to oversee it, it has to malleable enough that we can maintain it bit by bit over time
[0]: https://nx.dev/
[1]: https://rushjs.io/
[2]: https://github.com/google/wireit
[3]: https://turborepo.org/docs