If your makefile fixes up a file using sed and your system has gnu sed, your makefile may fail on a system with BSD sed (e.g., a mac). If you rely on bash-isms, your makefile may not work on a debian system where it will be run with dash instead of bash. And so on.
If you look in your package.json, you'll surely see a dozen or so "scripts" lines that run through the same shell that make does and have all the problems you just mentioned.
I'd also like to point out that Linux and almost certainly your production environment (because it's most likely *ix) will be case sensitive. Your macOS or Windows file system? Not so much. Point is, you're already up to your neck in portability issues. My macOS coworkers often forget this detail.
huh?? No it's not. That's the whole discussion we are having now. I even specifically mentioned my macOS coworkers who develop on their Mac and are oblivious to case-sensitivity issues. Because "it worked for me."
> If an external package has scripts in it, those scripts have very likely been run by somebody on a mac and somebody on linux and worked in both cases.
Oh, I'd love for that to be true. But also not what I was referring to. Most large projects have a "scripts" section and those are no different than Makefile commands. If you're paranoid about your own Makefiles then you're going to need to be paranoid about your own package.json.
Also, I use javascript where it makes sense: I rely on Browserify to resolve the web of `require`d files.
task: dependency
list of
commands
Regardless of whether the editor can or not, I just don't see how insisting on tab and not space is remotely defensible.
Vim does handle this. Here is Vim (and I've removed my .vimrc file, so this is not a setting I have set personally), on a Makefile where the third line erroneously uses spaces:
https://i.imgur.com/xMHXeL4.png
> I just don't see how insisting on tab and not space is remotely defensible.
This is like insisting that people haven't been having religious wars over this sort topic for years. You can see the Wiki[1] page on it (which starts "This is one of the eternal Holy Wars") for arguments as to why someone might prefer tabs. I personally like them because they allow the reader of the code to choose the visual layout of the indentation.
Now, while I love tabs, I work in Python all day. But good editors, like Vim, allow you to customize the indentation settings sufficiently to handle both cases like Python (spaces for indent) and Makefile (tabs) gracefully. So "Indent" and "Dedent" just do The Right Thing™ and it mostly never matters.
target : requisites ; recipe
However, tabs are beautiful, and every occasion to use them should be cherised as precious.
> remotely defensible
Feel free to write your own make superset that supports spaces. It's an irrelevant factor to the usability of make as a whole.
Multiple times.
Actually writing a preprocessor for Make sounds like a pretty good idea.
My pet theory is that the more experience you have, the more likely you are to have worked with Python, which is a lot easier to work with if you just always s/\t/ / (replace tabs with spaces).
FWIW, Webpack 4 (which just went final a few days ago) now has "zero-config" defaults out of the box. You may want to give that a shot.
One target to build (prod), another to run with fsevents doing auto-rebuild when a file is saved (instant gratification during dev), then a few targets for cleaup & housekeeping. All said, the file is 1/4 the size of any other JS-based build systems.