2 min read
Taskfile project introduction
I spend a lot of time on my https://taskfile.build/ project. What started as a standard to run any git project with bash, has become a command library for a wide range of software tools.
Every git project I am working with has a task script (aka Taskfile) in its root. The Taskfile provides all functions to run the project. No need to learn language-specific tools or specific commands to launch the dev environment or build the software. Simply check the available commands with ./task help and run them with ./task <command> [options].
The idea of a task script is not new and if I am correct the Makefile was the first of its kind. There are other very similar projects like just (Rust implementation of make) or Task (Go binary to run commands). Both of these projects require you to install a binary and that is a dependency that the Taskfile does not have. This sounds like a minor issue, but when you want to run your software in any environment it matters.
Ghosts of the past
When I reflected on what the Taskfile project has become, I realized that I am rebuilding my PowerShell PowerUp project. I built PowerShell PowerUp (PP+) 12 years ago to improve the shell experience on Windows. This project escalated into what I believe was the command line package manager for Windows (Chocolatey and NuGet came afterward). Not sure if I should be worried about this pattern repeating itself. Here is an interesting example:
Install “Sublime Text” with PowerUp on Windows: https://codeberg.org/janikvonrotz/PowerShell-PowerUp/src/branch/master/lib/App/Install-Sublime%20Text.ps1
Install “Sublime Text” with Taskfile on Arch Linux: https://codeberg.org/janikvonrotz/dotfiles/src/branch/main/packages/sublime
Funny enough I am still using Sublime as my default editor. I even bought a license!
Let’s check again in 12 years.
Category: software-toolingTags: 100daystooffload , bash , taskfile , task-runner , powershell , powerup
Edit Page / Show Statistic