(I generally find a small set of shell scripts work, or just three or four rules in the package.json file I can access with `npm run`).
The main problem `make` solved was not wasting work rebuilding dependencies that hadn't changed, but in 2023 on modern computers I don't notice the CPU cycles burned on that kind of thing.
(... if I do start to notice them, I reach for a tool like bazel, because it can handle spaces in filenames).
[Just]: https://github.com/casey/just
I generally reach for a shell script with "case" instead, though. Can always invoke make from the shell script.
It's true that more modern tools have features make doesn't (especially with regard to manipulating complicated dependency graphs) or attack parts of the problem that make doesn't (hermetic build environments, language-aware features like package management).
But... I can't see "lack of ability to do basic stuff" as one of its problems. What basic things are you trying to do?
What I want out of task runners nowadays is to run tasks. If I can't make a task without writing '.PHONY' - there's a problem with the task runner.
My blog, for example, has make targets for things like making a production build, publishing, cleaning out generated artifacts, and running a dev build (with drafts) + bringing up the test server.
Last year I wrote a little post about how I also use make + nix-shell to supply dependencies for Makefile tasks without needing to have them on my PATH: https://t-ravis.com/post/nix/nix-make/
Super ergonomic.
Though I have to admit, Go and Rust projects hardly needed `just`; the `go` program and the `cargo` tool are that good. I used `just` in them mostly to have short aliases and common names for tasks.
It depends on what you're producing as output.
One of my golang projects needs `-s -w -X '' -trimpath` along with separate GOOS and GOARCH depending on platform.
It is nice to have all that documented in a build file.
There's some good things about Makefiles, yes, but there's also a lot of weird legacy functionality. Make was meant to create files and directories, and the .PHONY functionality seems to be a workaround added to make it usable as a general-purpose task runner.
Just today I was trying to help a friend build some tool with Bazel. While I'm sure there's a reason for Bazels existence, but it's just way to complex. The build failed and debugging the Bazel config was just a major hassle compared to had we just looked at the Java commands in a Makefile.
Similar with Pythons setuptools, even though that is significantly easier with the new pyproject.toml. It's really powerful, but what all I wanted is basically to copy a bunch of files and add a bit of metadata.
I think many modern web-build tools were made by people who thought "hey, I can do better than make" (or worse, "What's make?" and reinvented the wheel) and then wound up in a similar conundrum.
I'm very happy with Make, though I have to agree, the syntax could be better. I don't mind using tabs, but why are spaces not OK as well? It would also be good to be able to not have to break long lines or multiline things with backslashes all the time. Yes you can set that oneshell thingy, but that is inconvenient in other ways, because it is for the whole file instead of a single command or a single target.
So it could be better, definitely, but it does the job of doing DAGs well and it is available on most systems, so I don't have to add some huge tree of dependencies just to run tasks.
I written[1] a blog on that as well. Glad to see there are more like minded people out there.
[1] https://www.yieldcode.blog/post/why-you-should-adpot-makefil...
Edit: I don't see a publicized image - added an issue: https://github.com/casey/just/issues/1497
However, anyone could add a docker just for just for their own project and use it to pull in just for all their projects, avoiding a download command to get just in other Containerfiles.
* each line executes in an isolated environment
* can't pass options or arguments to a make target
* not portable to other operating systems
the author is already using node packages. purpose-built taskrunners are plentiful, and the resulting scripts will be written in the same language as the rest of the codebase instead of adding a second language.
hiding a tool behind a makefile is my pet peeve. a proper taskrunner makes common operations easy without kneecapping the flexibility of the underlying tools.
Compared to make, one thing I like about cargo is I don't need to worry about the current directory as much. e.g. "cargo check" works from anywhere in my workspace but something like "make check" will fail if the Makefile isn't in the current directory.
Yes I know I could probably create an alias, direnv or something to improve make's behavior but I'd rather not have more things to manage. All this stuff is too complicated as it is. Overall the cargo defaults are much more ergonomic.
How about converting electron-forge-webpack-ts to make. That would be epic.
The claim that 157 ms and 126 ms is "shockingly slow" is quite an exaggeration.
Also they take even longer to start in CI/CD containers.
I ended up using Make after experiencing web project builder merry-go-round du jour of Grunt, Gulp, npm/yarn scripts, WebPack, etc.
Of course I had read all of the Make FUD… but like almost all things in computing (Vim vs. Emacs, tabs vs. spaces, Mac vs. Windows) you can't take it too seriously.
For me, similarly to when I went through several editors before I discovered Vim, Make has been around long enough and people have used it to address the hairiest build/dependency issues that many of the new tools have yet to address.
Let me address a few common issues.
IMHO the syntax isn't that bad. Like almost any programming language, you can write a clean, well-documented Makefile following best practices or you can slap something together with no planning and have an indecipherable page of junk.
And like many languages, many folks never learn to write Makefiles properly. I get it—most Makefiles in the wild are close to unreadable and are mostly undocumented.
And because Make has been around since the '70s, there's lots of hard-earned wisdom in blog posts and forums readily available going back decades.
O’Reilly's book "Managing Projects with GNU Make" (3rd edition) does a great job at getting someone up and running with Make. And the online documentation [1] is also quite good.
But the most important thing is I'm much more productive using Make instead of messing around with the various JavaScript build tools and their plugins. It's easy to integrate JavaScript, command line, Ruby, etc. tools with Make to get my projects built, linted, tested, packaged and deployed.
And having native support for Make in Vim/Neovim [2] is just the cherry on top. And it's still under active development [3] with bug fixes and new features.
Perhaps the best thing about Make: there's no dependency graph/build web project issue it can't handle. Writing clean, readable and well-documented may take a little more effort but it's worth it IMHO.
[1]: https://www.gnu.org/software/make/
