Skip to main content
@spree/cli ships a plugin new command that scaffolds the whole plugin monorepo for you. Generated layout:
You get a working “Brands”-style plugin out of the box: nav entry, a list page wired through React Query, a product-detail slot card, and English translations.

Run it

The CLI prompts for:
  • Plugin name — slug (kebab-case), used for package names and i18n keys
  • Ruby gem name — only matters if you later add a Rails engine
  • Module name — PascalCase, used as the React component prefix (MyPluginCard)
  • npm scope — e.g., @acme
  • Author + email — for package.json and LICENSE; prefilled from git config user.name / user.email
  • License — MIT, Apache-2.0, or BSD-3-Clause (MIT by default); the CLI fills in the standard text
Every prompt has a matching flag:
For CI and scripted use, -y / --yes accepts the default for anything the flags leave unanswered — author and email come from your git config, everything else derives from the plugin name:
--force overwrites an existing directory. --no-dashboard skips the dashboard package (Rails-engine-only plugins). --no-engine is reserved — engine scaffolding lands later.

After scaffolding

You now have a buildable plugin. The next page covers what to put in package.json for publishing — but if you’re using it internally and importing by path, you can stop here and skip Publishing.

What the entry-point looks like

packages/dashboard/src/index.tsx is where everything starts. The generated version, trimmed:
That’s the whole entry-point. Edit it to register what your plugin needs and remove what it doesn’t.

The example endpoints

The generated client.ts calls adminClient.request() against /<name> (relative to /api/v3/admin) — those endpoints don’t exist by default. You’d add them on the Rails side (a controller, a model, a serializer) for the plugin to do anything end-to-end. The CLI doesn’t scaffold the Rails engine today; for now, write that part by hand using the backend integration docs.

Reference