WeeChad is a small Bash-based configurator with a VitePress documentation site.
setup: main executable installer and WeeChat configuration source.GNUmakefile: ShellCheck and VitePress development targets.README.md: user-facing introduction, installation guide, and FAQ.docs/.vitepress/: site configuration and the Dyne-branded theme.docs/*.md: user guides and project documentation.docs/public/: static documentation assets.LICENSE.txt: project license.
Keep runtime behavior in setup; do not split it into extra modules unless that
clearly reduces complexity. Keep documentation assets under docs/.
make check: run ShellCheck againstsetup. Run this after every shell change.make deps: install the VitePress dependencies underdocs/.make docs: build the production documentation site.make preview: serve the documentation locally with live reload.NICK=tester bash setup: exercise the installer locally. This writes to~/.weechadand~/weechad, so use a disposableHOMEwhen testing.
There is no separate compilation step or automated test suite.
Write portable, readable Bash and keep the existing two-space indentation.
Quote variable expansions unless intentional word splitting is required.
Functions use descriptive kebab-case names such as setup-theme-conf;
variables use lowercase snake_case such as server_conf. Prefer shell built-ins
and straightforward control flow. Add brief comments only where behavior or a
side effect is not obvious.
Run make check before submitting changes. Avoid adding dependencies unless
the change cannot reasonably use the existing shell and MkDocs toolchain.
For installer changes, combine make check with a manual run using a temporary
home directory, for example:
tmp_home=$(mktemp -d)
HOME="$tmp_home" NICK=tester bash setupInstaller tests require WeeChat and may download scripts. Verify generated
configuration, permissions, and failure paths without touching real user data.
For documentation changes, run make docs and inspect the site with
make preview when visual behavior changes.
History uses short, imperative, lowercase summaries such as improve theme and
add queryman script by default. Keep each commit focused on one behavior.
Pull requests should explain the user-visible change, list commands run, and note installer side effects or platform assumptions. Link related issues. Include screenshots only for rendered documentation or visual theme changes.