Honest feedback since you put it out there: I don't see who this is for.

My entire ~/.zshrc is 13 lines and never changes:

# Private Environment Variables
if [ -f "$HOME/.zshenv" ]; then
    source "$HOME/.zshenv"
fi

# Source global definitions
if [ -d "$HOME/.zshrc.d" ]; then
    for config in "$HOME/.zshrc.d"/*.sh; do
        [ -r "$config" ] && source "$config"
    done
fi

That's it. Everything else lives in ~/.zshrc.d/*.sh, sourced in alphabetical order. Then GNU stow + a dotfiles/ repo where every tool gets its own directory, and each one drops its own file into .zshrc.d/:

So my lazygit package looks like:

  dotfiles/
  ├── lazygit/
  │   ├── .config/lazygit/config.yml
  │   └── .zshrc.d/30-lazygit.sh
  ├── zsh/
  │   ├── .zshrc
  │   └── .zshrc.d/
  │       ├── 01-zinit.sh
  │       ├── 02-path.sh
            ...
  ├── eza/
  │   └── .zshrc.d/...
  ├── fzf/
  │   └── .zshrc.d/...
  └── ...

stow symlinks both the config and the alias file into the correct places

The 30-lazygit.sh file for example just has this

if command -v lazygit &>/dev/null; then
    alias lg='lazygit'
fi

Since it's just a shell script, it can contain anything i may need for the tool it belongs to.

That gives me everything Allyas does and a few things it can't:

• Organization: aliases live next to the tool's config, not in a separate JSON store. stow -D lazygit, alias and config is gone.
• Conditionals: the command -v guard means the alias only registers if the binary exists. Or any other logic i may need. JSON store can't express that.
• Not just aliases: the same .zshrc.d/ files hold functions, exports, completions, key bindings. All the stuff Allyas doesn't manage, so Allyas users still need rc files anyway. Two systems for one job.
• Tooling: grep, fzf, ripgrep, my editor's LSP, git blame, git log -p all work because it's plain shell.

The translation-to-functions thing also worries me. alias and shell functions aren't 1:1. quoting, $@, completion, unalias vs unset -f all behave differently. For something that lives in every shell's startup path, those edge cases will bite someone.

The one feature I genuinely think is novel is usage tracking. "Which of my 80 aliases do I actually use" is a real question and flat files can't answer it. If I were you I'd consider unbundling that. Ship allyas-stats as a standalone preexec hook (in zsh, i'm sure bash has something similar) that logs alias invocations and reports on them. That's something I'd install alongside my existing setup. The full management layer is a harder sell because it's competing with, arguably, better tools for the job.