It's interesting, but I can't help but think that by the time you're adding `.PHONY` after most rules, you're not using the right tool for the job.

(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`).

I tried repeatedly to just stick with Makefiles but I kept having to add workaround and hack to do basic stuff. They got uglier and uglier. I checked out go task and cargo make, but eventually gave in to `just`. It has worked just fine and the files are infinitely more readable than the comparable ones w/ make.

I haven't played around with the make-alikes, but I have also taken to using make for this sort of thing.

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/

Just [0] was discussed on HN. I think I'll give that a shot next time I have to write something like this. .PHONY is lame.

[0] https://news.ycombinator.com/item?id=34315779

Make becomes a pretty terrible tool at a fairly low level of complexity. I would never choose it voluntarily to build things.

It is at least much better than having tasks and their dependencies merely specified as plain strings in a package.json file, as unstructured data, out of which the tool (npm) does not have any knowledge about dependencies and simply runs all strings as commands. This is done by countless web projects and it is embarrassing. I would rather have a package.json script that calls Make, than define my steps in the package.json itself.

My main problem with make: When you want to write sophisticated build processes, the syntax is bizarre and difficult to work with.

Totally agree with the author. As someone who jumps between multiple projects, in different languages-I have hard time remembering what build/test/script runner in used in particular project. Hell, even two JS/TS projects can use different tools (one could use npm with jest, the other yarn with webpack, etc).

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...

This is sweet but `just` is even sweeter - can use multistage build files to elegantly add it to any Containerfile, no?

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.

I realize that I have been using shell scripts for this. I just copy-paste commands and add a selector. It has the benefit that I didn't need to learn a new syntax.

`make` is not a taskrunner, it is for tracking dependencies between files. a .PHONY target that isn't named "all", "clean", or "dist" is a code smell. there are many design decisions in `make` that are the opposite of what you want in a taskrunner:

* 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.

I've done things this way for many years but now that I'm working with rust I find myself doing more with cargo instead.

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.

Just making a bunch of phony rules is writing a shell script with extra steps.

How about converting electron-forge-webpack-ts to make. That would be epic.

I’m unconvinced. I don’t see a reasonable benefit for learning yet another config syntax just to run some scripts.

I went through my Makefile stage. It can be nice but it can also get messy and ugly. If you're doing simple tasks fine but your project still needs to have a lot things anyways that negates its usefulness.

I tried this for a bit until I found out make couldn't deal with spaces in the file name. switched to rake (ruby), which had the advantage of not needing to write separate shell scripts.

>People routinely point out that npm/yarn scripts are shockingly slow to start

The claim that 157 ms and 126 ms is "shockingly slow" is quite an exaggeration.

Before a couple of years ago, I had never written a Makefile in my life.

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/

[2]: https://vimways.org/2018/runtime-hackery/

[3]: https://lwn.net/Articles/913253/