Historically, I did it the other way around: have some autogenerated shell commands (dev, test, pull...etc) on my local machine that detect which language the project in the current folder is using, and calls commands accordingly.
I did it this way because, in my case, it was challenging to consolidate multiple projects across multiple organizations under a single tool.
Even for projects where Make isn't part of the build pipeline, like Rails or C++, I have a standardized makefile I put in the project root, using includes for "secrets.mk", so I can do things like "make deploy" and it Just Works(tm).
Another neat and simple trick it to have the first target in the Makefile print out a helpful message that tells the reader what the project is and how to use it. One of those things that is useful both when you are working on the project and when you later return to it, years later.
I wish mise has better secrets management or allows for split config e.g. a repo wide config that's to be shared and a personal config that can override whatever's necessary. It's difficult to commit mise.toml because the [env] section almost always contains sensitive variables.
Historically, I did it the other way around: have some autogenerated shell commands (dev, test, pull...etc) on my local machine that detect which language the project in the current folder is using, and calls commands accordingly. I did it this way because, in my case, it was challenging to consolidate multiple projects across multiple organizations under a single tool.
It's public, but I realize I haven't pushed my local updates for a while now. https://github.com/Betree/dev-commander
I do this with plain ol' makefiles.
Even for projects where Make isn't part of the build pipeline, like Rails or C++, I have a standardized makefile I put in the project root, using includes for "secrets.mk", so I can do things like "make deploy" and it Just Works(tm).
Sometimes the old ways are best!
Another neat and simple trick it to have the first target in the Makefile print out a helpful message that tells the reader what the project is and how to use it. One of those things that is useful both when you are working on the project and when you later return to it, years later.
That's definitely an option, though I prefer to just put a README. No reason you couldn't have the default make target just execute `cat README.md`
I've been using Taskfile. Are just / mise much better?
Taskfile is great but I’ve moved to mise over a year ago and not coming back.
The only think I found Taskfile does better is handling Go’s defer. Misé unfortunately does not have an equivalent.
Mise manages tools, env vars, tasks, bootstrapping , plays well with usage, etc.
People saying "just use makefiles" are missing out.
Not using YAML is huge.
I wish mise has better secrets management or allows for split config e.g. a repo wide config that's to be shared and a personal config that can override whatever's necessary. It's difficult to commit mise.toml because the [env] section almost always contains sensitive variables.
mise looks in a number of places for configuration and recommends using a `mise.local.toml` file for local-only configurations:
https://mise.jdx.dev/configuration.html
the same author has a separate but related project called fnox which focuses on secrets management and integrates with mise:
https://fnox.jdx.dev/
Are you aware of fnox by the same author?
https://fnox.jdx.dev/