Makefiles for Web Projects: Manage Your Environment Workflow
Makefiles for Web Projects: Manage Your Environment Workflow How I stopped worrying and loved Makefiles Note: Makefile indentation must use tabs, otherwise you’ll get syntax errors.
The Core of a Makefile: Targets up: cp .env.example .env docker compose up -d workspace stop: docker compose stop zsh: docker compose exec workspace zsh This example has three targets: up, stop, and zsh. By default, Make treats the first target as the Goal (it cannot start with a dot), which is the project’s primary workflow. In this case, make and make up do the same thing. But the copy step above is not a typical Make use case. Make shines at deciding whether each target needs to run. For example, we often store secrets in .env. If .env already exists, we shouldn’t overwrite it by copying .env.example again. In that case, we can make .env a target: up: .env docker compose up -d workspace .env: cp .env.example .env By default, target names are treated as filenames. The name “make” implies building a target; it will only execute the target’s recipe when the conditions are met (like the file not existing). In this example, when you run the up target, if .env doesn’t exist it will run the .env target first to create it, then start the workspace container. If .env already exists, it skips the .env target and starts the container directly. Likewise, if there is a file named up in the directory, the up target won’t run. You can define Phony Targets to tell Make that certain targets aren’t filenames, but named workflows instead: .PHONY: up stop zsh Add Some Variables Make supports variables (Variable). Following common Unix environment variable conventions, we usually write them in SCREAMING_SNAKE_CASE. When used, variables are wrapped in $().
