A lightweight watcher inspired by antr and entr. See also: funzzy.nvim
Configure auto-execution of different commands using semantic YAML and Unix shell style pattern match or stdin.
For a workflow as simple as:
find . -name '*.ts' | funzzy 'npx eslint .'
Or more complex workflows like:
# .watch.yaml (or .watch.yml)
# list here all the events and the commands that it should execute
# TIP: include '.watch.yaml' in your .git/info/exclude to ignore it.
# TIP2: List the tasks/steps from quicker to slower for better workflows
#
# Run: `fzz --fail-fast --non-block` (`fzz -nb`) to start this workflow (min: v1.4.0)
- name: run my tests
run: make test
change: "tests/**"
ignore: "tests/integration/**"
run_on_init: true
- name: Starwars ascii art
run: telnet towel.blinkenlights.nl
change:
- "/tmp/starwars.txt"
- ".watch.yaml"
# Command templates for custom scripts
- name: run test & linter for a single file
run:
- "npm run lint -- {{relative_path}}",
- "npm test -- $(echo '{{filepath}}' | sed -r s/.(j|t)sx?//)"
change: ["src/**", "libs/**"]
ignore: ["src/**/*.stories.*", "libs/**/*.log"]
- name: run ci checks @quick @ci
run: | ## Watch with `fzz -t @ci`
cat .github/workflows/on-push.yml \
| yq '.jobs | .[] | .steps | .[] | .run | select(. != null)' \
| xargs -I {} bash -c {}
change: "src/**"
run_on_init: true
- name: finally stage the changed files in git
run:
- git add {{relative_path}}
- git commit
change:
- "src/**"
- "tests/**"
ignore: "**/*.log"
Want more examples?
Funzzy pairs well with these tools:
-
yq - A yaml querier similar to
jq
to extract commands from GitHub Actions! -
nrr - For JS/TS projects, since Funzzy runs commands on change, a faster task runner makes a difference
To create a lightweight watcher that allows me to set up personal local workflows with specific automated checks and steps, similar to GitHub Actions. Funzzy was built with Rust, which makes it blazingly fast and light.
brew tap cristianoliveira/tap
brew update
brew install funzzy
curl -s https://raw.githubusercontent.com/cristianoliveira/funzzy/master/linux-install.sh | sh
You can specify the versions:
curl -s https://raw.githubusercontent.com/cristianoliveira/funzzy/master/linux-install.sh | bash - 1.0.0
nix-env -iA nixpkgs.funzzy
nix profile install 'github:cristianoliveira/funzzy'
# or
nix profile install 'github:cristianoliveira/nixpkgs#funzzy'
Install nightly version:
nix profile install 'github:cristianoliveira/funzzy#nightly'
or, if you use shell.nix
:
{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
buildInputs = [
pkgs.funzzy
];
};
cargo install funzzy
*Make sure you have $HOME/.cargo/bin
in your PATH
export PATH=$HOME/.cargo/bin:$PATH
- From source
Make sure you have installed the following dependencies:
- Rust
- Cargo
Execute:
cargo install --git https://github.com/cristianoliveira/funzzy.git
Or, clone this repo and run:
make install
Initializing with boilerplate:
funzzy init
Change the config file .watch.yaml
as you want. Then run:
funzzy
# or use the short version
fzz
Check all the options with fzz --help
Use a different config file:
fzz -c ~/watch.yaml
Fail fast which bails the execution if any task fails. Useful for workflows that depend on all task to be successful. See its usage in our workflow
fzz --fail-fast # or fzz -b (bail)
Filtering tasks by target.
fzz -t "@quick"
# Assuming you have one or more tasks with `@quick` in the name, it will only load those tasks
Run with some arbitrary command and stdin
find . -name '*.rs' | fzz 'cargo build'
Templates for composing commands
find . -name '*.[jt]s' | fzz 'npx eslint {{filepath}}'
Run in "non-block" mode, which cancels the currently running task when there are new change events from files. It's super useful when a workflow contains long-running tasks. See more in long task test
fzz --non-block # or fzz -n
This might be due to different causes, the most common issue when using VIM is because of its default backup setting which causes changes to multiple files on save. (See Why does Vim save files with a ~ extension?). For such cases either disable the backup or ignore them in your watch rules.
For other cases use the verbose fzz -V | grep 'Triggered by'
to understand what is triggering a task to be executed.
Running unit tests:
cargo test
or simple make tests
Running integration tests:
make integration
We use rustfmt
to format the code. To format the code run:
cargo fmt
- Fork it!
- Create your feature branch:
git checkout -b my-new-feature
- Commit your changes:
git commit -am 'Add some feature'
- Push to the branch:
git push origin my-new-feature
- Submit a pull request
- Open pull requests
- Create Issues
- Report bugs
- Suggest new features or enhancements
Any help is appreciated!
Pull Request should have unit tests
This project was made under MIT License.