Note that this target asks for y/N confirmation before anything is executed, and also runs the tidy, audit and no-dirty checks first.
This automatically runs the tidy and audit quality-control checks first, and no-dirty to check that there are no uncommitted changes to tracked files. push: Push changes to the remote Git repository.Depending on the project I often add more to this section, such as targets for connecting to a development database instance and managing SQL migrations.When changes are made to any files with the specified extensions, the application is rebuilt and the binary is re-run. run/live: Use the air tool to run the application with live reloading enabled.Note that my main reason for not using go run here is that go run doesn't embed build info in the binary. run: Calls the build target and then runs the binary.
#Makefile vs runjs code#
Note: You can also find the Makefile code in this Gist. It's generic enough that you should be able to use it as-is for almost all projects. While the exact contents of the Makefile changes from project to project, in this post, I want to share the boilerplate that I'm currently using as a starting point. I find that it's a simple way to save time and mental overhead, as well as helping me to catch potential problems early and keep my codebases in good shape. The first is to automate common admin tasks (like running tests, checking for vulnerabilities, pushing changes to a remote repository, and deploying to production), and the second is to provide short aliases for Go commands that are long or difficult to remember. Whenever I start a new Go project, one of the first things I do is create a Makefile in the root of my project directory.
0 kommentar(er)
