Jolter adoption works best when the repository tells developers exactly what to install, what to commit, and how to verify their environment.
Add project configuration
Start with a root jolter.json:
jolter pin node@24
jolter pin pnpm@10
jolter sync
jolter doctor
git add jolter.json
git commit -m "Add Jolter toolchain configuration"
Update your repository README
Add a short setup section:
## Toolchain
Install Jolter:
```bash
curl -fsSL https://get.jolter.dev/install.sh | sh
jolter setup
jolter sync
jolter doctor
```
Windows users can install with:
```powershell
irm https://get.jolter.dev/install.ps1 | iex
```
Prepare CI before requiring it locally
Add jolter setup-ci to CI before enforcing Jolter locally:
- name: Install Jolter
run: |
curl -fsSL https://get.jolter.dev/install.sh | sh
jolter setup-ci --no-progress
jolter setup
jolter sync
jolter doctor
Communicate PATH expectations
Tell contributors that Jolter shims should appear before other Node.js managers on PATH.
Doctor will identify common conflicts with nvm, fnm, Volta, Corepack, system Node.js, or package-manager global bins.
Keep rollback simple
Jolter does not modify package manager lockfiles or project source. A rollback usually means reverting jolter.json and removing the CI setup step.
Installed data under JOLTER_HOME is rebuildable state. Contributors can keep it or remove it after uninstalling Jolter.
Adoption checklist
A good rollout has a committed jolter.json, a passing CI setup-ci step,
README instructions, a known support contact, and a clear policy for when
selectors may be changed.
