11–16 of 16 posts
Looks nice. As someone unfamiliar with Make, can someone explain why YAML is a bad idea for something like this? My favorite part (unironically) is how this is written in TypeScript. Easier for me to contribute features and fixes.
Btw, you should add a JSON schema for the build.yaml data, so VSCode can provide auto completion. https://brunopaz.dev/blog/how-to-create-your-own-auto-comple...
So, a Makefile written in YAML?
This looks very similar to https://taskfile.dev (Go, 3.5k stars).
Thats very true, I used taskfile personally and professionally for a few projects and encoutered some problems I tried to solve with this project. I even tried to contribute there, but it was not that easy, since I am not that fluent in go
Earlier quoted context omitted.
Thats very true, I used taskfile personally and professionally for a few projects and encoutered some problems I tried to solve with this project. I even tried to contribute there, but it was not that easy, since I am not that fluent in go
I'm curious: what kind of problems?
- without docker images in tasks tooling was not always the same on different machines
- a docker image that can be used for gitlab ci
- caching on CI systems was a huge effort, requiring to specify all .task directories and build directories
- limited includes of other build files, no nesting or loops, making project style taskfiles not possible
- the cwd of includes is not relative to the reference taskfile
- detect changes in cwd during commands, for example with `cd ..`
- a service definition, allowing to use databases with some healthchecks to detect startup delays
- limiting cpu/memory of build steps / limiting tasks that are executed parallel by resource availableLooks nice. As someone unfamiliar with Make, can someone explain why YAML is a bad idea for something like this? My favorite part (unironically) is how this is written in TypeScript. Easier for me to contribute features and fixes.