I understand the simplicity angle. https://github.com/elasticdog/transcrypt has been around for a long time and strikes that balance very well in my opinion. And it's just a bash script that can also be committed so the git repo is atomic.
Been doing it for more than a decade and yet to get in trouble. Not one issue. Doing it consistently for my teams as we decrease cognitive load (developing on macs but targeting unix). Others would confirm https://news.ycombinator.com/item?id=17943202
Basically software will either use absolute paths i.e. wants to use your OS version for a dependency like grep, or will use whatever grep is in your $PATH and stick to safe invocations regardless if it's BSD/GNU or if it's version x or y
KATT https://github.com/for-GET/katt is the same concept, but following the pattern matching philosophy. Written in Erlang, available as a CLI tool as well but needs the erlang runtime installed.
Disclaimer: I'm one of the authors, thus biased, but the reason I'm mentioning KATT is that the low barrier of entry for captures and asserts makes it a nice requirement tool for non-techs to write complex API scenarios.
It uses well-tested software (GNU Make, Bash, Homebrew, Docker)
and there's not much to learn really.
* Incubated at Tobii (eyetracking, Sweden),
* it has been used for several projects of different sizes,
* tested on 12+ CIs !
* tested on macOS, Linux and Windows (WSL) !
* tested on 8+ Linux distros !
* comes with prebuilt Docker images !
Early integration with VSCode. And much more. Just read the README :)
When you say everything contained in the project, you forget that there's more to life than just node/javascript. Just two silly examples: you cannot run/deploy your API backend without docker/kubernetes/aws-cli/etc, nor your mobile app even if it's in JavaScript (react-native).
The only way to keep to node/javascript is if you only develop libraries (a website that doesn't get deployed -> still on library level).
Nowadays there's Windows Subsystem for Linux. There's no excuse not to successfully run "Linux" scripts on Windows.
I've been running very complex build systems via https://github.com/ysoftwareab/yplatform (disclaimer: author here) since 2016 on Linux, Mac and Windows without a problem.
As others have mentioned on this thread, the problem is not just "use Makefiles instead of package.json scripts", but quickly ending up with duplicate Makefile content and then supporting more than just one language. It's inevitable.
PS
for those that don’t know, npm’s “scripts” functionality as we know it today was not “designed”, but it was simply a byproduct.
PS: quite feature complete but not yet well marketed so to speak. I'm actually recording an asciinema session this week in order for a visitor to grasp quicker the mentioned benefits.
> GNU Make is a tool which controls the generation of executables and other non-source files of a program from the program's source files.
What is idiosyncratic is to think Make is first a command runner, and only after a file generator, and complain that it is doing a poor job at the former when it clearly says it is focusing on the latter.
I read the "idiosyncrasies" section on the just README and they are all performance related targeting file generation. All of those can be learned in one minute, as part of "I'll always find Makefiles in the wild, it's good to know the basics".
Funny but I've also done this.
Thanks for sharing!
Depending on the context, if you don't want this in git history, and want to handle git submodules, there's also git-archive-all https://github.com/roehling/git-archive-all (if you like shell scripts, it is using bats for testing - it was the first time I heard of it)
My 2c are that the problem is there, not specifically to OSS. The whole industry is looking down on maintenance and maintainers.
Keeping things working might not be a great career, but it's equally important as creating new stuff, and guess what: some people don't want to create but like to debug and maintain.
A parallel might be drawn with the right to repair electronics. When we will get back the culture of repairing stuff, then we will value more the act of repairing. Because now, it's an art of repairing that very few afford.
I've also been having bash as a strict req for tool language. As you say there are 1% or less cases where you can benefit from using smth else but that's 1%!
My team had js as the main language and that's what we had that 1% in. Mostly no-deps scripts but where deps where needed we could hack around npx to install the deps on-demands. I would use deno today for that actually.
But! Almost nobody gets it. If you're into operations: "here we write our tool chain in Python". If you're into dev: "here we write our tool chain in js/go/php/etc/etc Bash would just be a +1"
+1??? You still need to write bash, or shell in general, for orchestration of build/ci/cd pipelines. If someone thinks that in 2021 they can escape learning shell, they are out of their minds. So no, it's not a +1.
As devs we should spend 10x more on solid foundations that work as many of us, for as many years to come, than we do on hip-new-thingie-that-promises-to-fix-all-my-problems. It's as if we took the regex joke and our brains could only comprehend: I'm never using a regex. Keep it simple? Never.