Getting Updates

Atomic CRM is meant to be forked and customized: there is no npm package to install as a dependency and upgrade. Instead, Atomic CRM components, hooks, and lib files are published as a shadcn registry, which you can use to pull upstream changes into your fork.

This registry is not meant to bootstrap a new project. If you’re starting a new CRM, follow the Installation instructions instead. The registry is only useful once you already have a running fork and want to catch up with upstream improvements (bug fixes, new features, dependency bumps in src/components/admin and src/components/ui).

One-off: Switching Your Fork to Base UI

Atomic CRM now builds on Base UI instead of Radix UI, following Shadcn Admin Kit 2.0. Before pulling this release into an older fork, switch your own components.json to the Base UI style:

{
  "style": "base-vega"
}

Skipping this step leaves the src/components/ui files your fork already owns on Radix while the incoming application code uses the Base UI API (render instead of asChild, an items map on <Select>, array values on <ToggleGroup>), and tsc will fail.

Your own components keep using Radix until you migrate them. Shadcn ships an agent skill for that, one component at a time:

pnpm dlx skills add shadcn/ui

Then ask your coding agent migrate accordion to base-ui, and so on. The Shadcn Admin Kit migration guide covers the details.

Refreshing Your Fork

Commit or stash any pending work first, this command overwrites files, and you’ll want a clean diff to review the changes:

npx shadcn add https://marmelab.com/atomic-crm/r/atomic-crm.json -o -y

• -o (--overwrite) replaces local files with the upstream version.
• -y (--yes) skips the interactive confirmation prompt. Prefer this flag over piping yes | into the command: it’s the option the CLI provides for non-interactive use, and it fails loudly if the CLI ever changes its prompts instead of silently answering “yes” to whatever comes up.

Once the command completes, review the diff:

git diff

Resolve any conflict with your own customizations, run the test suite (make test, make test-e2e), then commit.

What Gets Updated

The registry mirrors the files tracked by scripts/generate-registry.mjs: everything under src/components/atomic-crm, src/components/supabase, most of src/hooks, and most of src/lib. It does not touch your Supabase schema, your docs/project-context.json configuration, or any file you added outside those directories.

Keeping Your Own Fork’s Registry Up To Date

If you maintain your own fork long-term (for example to distribute your customized CRM to several deployments), regenerate and republish the registry the same way Atomic CRM’s CI does:

make registry-gen    # regenerates registry.json from the current source tree
make registry-build   # builds the distributable registry file
make registry-deploy  # publishes it (wraps registry-build)

See the main README for how these targets fit into the CI/CD pipeline.