91–100 of 176 posts
Earlier quoted context omitted.
Based on everyone's feedback about YAML (we didn't expect this much), we'll probably reconsider this!
Take a look at Apache Aurora [1] if you want some inspiration on how to mold python into a config language. I used this system for a few years and mainly agree with the person you're replying to – having a proper programming language to define config is a very nice feature that I miss. [1]: https://aurora.apache.org/
I reviewed the market for JS monorepo tools a few months back and found NX to be a strong choice. Looking at Moon it seems like the syntax is quite nice but I don’t see graph feature of NX? Can moon only run on affected packages?
> Tasks are defined and run as if you were running them in the terminal; no more abstractions like BUILD files. But abstractions are a good thing! They let you separate a system into layers, so that things programmed at a higher layer don't need to know all the details of the lower layers. It's the way we separate interface from implementation. Let me give an example from Bazel. Suppose you are compiling some C or C+…
Earlier quoted context omitted.
Can you talk a bit more about what kind of code is being copied?
The main repository is a single page app that's mostly Typescript compiled via Svelte down to a JavaScript bundle. Most of that repository is a series of modules in their own directories (e.g., "src/modules/character"). The second repository is a Node.js API. The majority of its functionality comes from one of the modules from the first repository that I copy in its entirety to the other repository whenever I change…
I'm supremely disappointed to see another service using YAML to configure task running. I do in fact need a real programming language to do this, and copying others in this vein is inheriting mistakes and not picking a battle-tested solution. What you will find is the vast majority of your configurations will invoke a make.sh script that does everything that you want to support in your system.
Feel like any data definition language eventually bolts on a shitty form of templates.
Earlier quoted context omitted.
I'm not trying to be overly critical here, in fact, I want to share the type of empathetic feedback I'd hope to receive as a founder. Have you actually talked to Blaze/Bazel users to understand what frustrations (if any) they have with their current build system? Have these users asked for a Bazel-lite? If so, and you still want to position yourself as Bazel-lite, then you should include some of their direct feedback…
Let me give them feedback in the vein of what you're asking for. I want the following as a user: - Distributed cache of built artifacts. Work with my company's network topology and security requirements. Make this easy to setup, operate, and seamless for developers to opt into - Seamless monorepo support (multiple languages) That could be considered Bazel-lite. And yes, I'd take it over Bazel currently. If you don't…
[1]: https://www.youtube.com/watch?v=t_3bckhV_YI
[2]: https://www.youtube.com/watch?v=H67uuwVO1tc
[3]: https://www.databricks.com/blog/2019/02/27/speedy-scala-buil...
Just is a task runner (with full shell integration) that calls our turborepo tasks.
We define all of our tasks in one justfile (things like repo setup, syncing env vars, and compiling dependencies) and then link them to turbo processes which cache the result.
Massively reduced our cognitive load working with our monorepo, and is lightning fast.
If we ever want to change it will be simple to remove both, so we're not tied to the ecosystem.
IMHO, if you're targeting the Javascript ecosystem, this area is already fairly crowded, with Turborepo, Nx and various open source tools providing various degrees of functionality (Bazel, Pants, Lerna, etc) already competing in the space. I'm a tech lead for the web monorepo at Uber. We talked to the Turborepo guy a few years ago, and he admitted that he wasn't sure if it could handle our scale in terms of all the b…
We agree. We weren't happy with all of the current solutions, at least in the JavaScript space. In regards to build graph invalidation, we attempt to hash pieces at the granular level. This includes per file content hashing, and for dependencies (those in `package.json`), we parse the lockfile and extract the resolved version/integrity hashes. We can probably improve this further, but this has been working great so f…
My IDE solves this in that I see red underlines, but I also want my build to fail as well. Not everyone uses an IDE that would show this error.
My advice to anyone making a new build system: Most likely you did this because you felt all the other ones are too complicated. But the reason the “enterprise” ones are so complicated is to serve their enterprise customers, who need “just this one feature” so they can use it. But those customers pay the bills. So basically you have to choose complexity and profit or simplicity and less (or no) profit. Good luck! But…
I'm supremely disappointed to see another service using YAML to configure task running. I do in fact need a real programming language to do this, and copying others in this vein is inheriting mistakes and not picking a battle-tested solution. What you will find is the vast majority of your configurations will invoke a make.sh script that does everything that you want to support in your system.
Yeah, I’m kind of aligned with this. Github workflow definitions would be much more pleasant to write if they were plain Typescript. Feel like any data definition language eventually bolts on a shitty form of templates.