As a developer, you may have had moments where you find yourself running the same bunch of commands repeatedly. For example, bumping package.json version, pushing to git, and publishing to NPM, whenever you wanna ship a new version of your NPM package.
I was facing the same issue. And given how lazy my brain is, I wanted to make this easier and simpler. So, I built Jido.
What is Jido?
Jido is a workflow automation CLI, where you can define your workflows (called flows) in a config file, and run them using npx jido flow <flowname>.
The config file is a jido.config.js in the project root. So, custom JS logic is also applicable, unlike Bash scripts.
Get started with jido by running:
npm install --save-dev jido
The Config File
The jido.config.js file call the jido() function and export it by default. It takes in an object as argument, which has the key flows that holds an array of objects, each object defining a flow.
Every flow has:
-
name: Name of the flow -
description(Optional): A short description about the flow -
steps: Array of objects, each object defining what each step would do
Each step is of the following form:
-
run: The command to be run at this step (eg, 'npm run dev' or 'git push' etc). -
onStart, onSuccess, onFailure: Optional hooks. These are functions that will be called on start, success and failure of the step. -
plugins: An array of objects, where each object is a plugin. We'll talk more about this in a while.
To scaffold a basic config file, run npx jido init. It'll generate the following config file:
import { jido } from "jido";
/*
* Define your workflows here.
* Each flow is a series of steps with commands to run and optional hooks (onStart, onSuccess, etc) to execute.
*/
const config = {
flows: [
{
name: "run",
description: "Run the project",
steps: [
{
run: "npm install",
onStart: () => console.log("Installing dependencies..."),
onSuccess: () => console.log("Dependencies installed!"),
plugins: [] // Any plugins go here
},
{
run: "npm run dev",
onStart: () => console.log("Starting dev server..."),
plugins: [] // Any plugins go here
}
]
}
]
}
export default jido(config);
Plugins
Now, another fun part of Jido. Plugins. A plugin is essentially an object of the following type:
type Plugin = {
onStart?: Hook;
onSuccess?: Hook;
onFailure?: Hook;
};
Basically, its an object with any or all of these hooks, which are attached to the step where the plugin is attached to.
However, the recommended way of writing a plugin is to write it in a function which returns an object of the above type. This allows in custom and argument-dependent functionality of a plugin.
For example:
// Plugin function
const myPlugin = (name) => {
return ({
onStart: () => {
console.log(`[myPlugin] Hello, ${name}! Step started...`);
}
});
}
// In a step in the config file:
plugins: [myPlugin("aether-flux")]
// In another step:
plugins: [myPlugin("John Doe")]
Now, Where Do You Use Jido?
Well, one of the use-cases is when publishing a new version of a package to NPM or anywhere else. That was the reason why I even thought of making this CLI.
There are many other applications as well. For instance:
- Deploy to vercel after a successful build.
- Clean + Reset project state before testing.
- Run local dev with custom logging and/or analytics tracking.
- Alert team (Slack, Discord, etc) after a successful build and deploy.
And anywhere else really, where you find yourself running the same bunch of tasks over and over again.
So, What Do You Think?
I hope Jido can simplify repetitive tasks for many devs out there, thus allowing them to focus more on the fun part (aka 'coding') rather than spending so much time just pushing to github and building and deploying and all that.
Do give it a chance in your workflow once. I'm sure it'd work wonders.
BTW, publishing any new version of Jido is being automated by jido.
Top comments (0)