@jeangrey/sbc
v0.5.0
Published
A vue-cli style interactive CLI to scaffold, search and run Spring Boot projects (monorepo-aware), powered by Spring Initializr.
Maintainers
Readme
sbc · Spring Boot CLI
English | 简体中文
A vue-cli style interactive CLI to scaffold, search and run Spring Boot projects — monorepo-aware, powered by Spring Initializr or the Alibaba Cloud mirror.
Features
- Scaffold projects interactively (prompts) or non-interactively (flags), just like
vue-cli. - Monorepo support:
--modulesscaffolds a real multi-module reactor — one aggregator, one wrapper, one command builds every module. - Search / filter dependencies by id, name or description — from the command line or a type-to-filter picker.
- Run a generated project through its Maven/Gradle wrapper (
spring-boot:run/bootRun). - Workspace manifest so
sbc list/sbc run <module>work across a tree of projects. - Multiple registries — switch between start.spring.io and start.aliyun.com per command, per project, or via an environment variable.
Install
npm install -g @jeangrey/sbc
# or run once
npx @jeangrey/sbcUsage
Create a project
# Interactive
sbc create my-app
# Non-interactive (any provided --deps or --modules enables non-interactive mode)
sbc create my-app --type maven-project --java 21 --group com.example -d web,data-jpa
# Generate a multi-module reactor instead of a single project
sbc create shop --modules api,core,web -d web
# Generate and run immediately
sbc create my-app -d web --runKey options:
| Option | Description |
| --- | --- |
| --type <id> | maven-project | gradle-project | gradle-project-kotlin |
| --modules <list> | Build a monorepo: api,core,web or api:web;core:jdbc,data-jpa |
| --language <lang> | java | kotlin | groovy |
| --boot <version> | Spring Boot version, e.g. 3.5.0 |
| --java <version> | Java version, e.g. 21 |
| --group / --artifact | Maven coordinates (--artifact is the root artifact in a monorepo) |
| --name / --description | Project name and description |
| --package <name> | Base package, e.g. com.example.demo |
| --packaging <type> | jar | war |
| -d, --deps <list> | Comma-separated dependency ids or names |
| --config-format <fmt> | properties | yml |
| --set <key=value> | Add an entry to the config file (repeatable) |
| -f, --force | Write into a non-empty directory |
| --run | Run the project after generating |
| --module <name> | Workspace module name to register |
| --registry <id> | Initializr registry: spring | aliyun, or a full URL |
Registries
sbc can scaffold from any Initializr-compatible service. Two are built in:
| Id | Service | Notes |
| --- | --- | --- |
| spring (default) | start.spring.io | Official service, newest Boot versions |
| aliyun | start.aliyun.com | Alibaba Cloud mirror, adds Spring Cloud Alibaba / Nacos / Sentinel / RocketMQ starters, faster from mainland China |
Pick one per invocation, persist it for a project, or set it in the environment:
# Per command
sbc create my-app --registry aliyun -d web,data-jpa
sbc search nacos --registry aliyun
# Persist for the project (writes sbc.config.json)
sbc config set registry aliyun
sbc create my-app -d web
# Environment variable
export SBC_REGISTRY=aliyunWhen nothing is configured, sbc create asks which registry to use interactively.
Any other Initializr service works too — pass its base URL, and the Boot version is normalised to a coordinate that exists on Maven Central:
sbc create my-app --registry https://start.example.com -d webSBC_REGISTRY, sbc.config.json and the flag accept the same values. Resolution
order, highest priority first: --registry → SBC_REGISTRY → the nearest
sbc.config.json (searched upwards from the target directory) → spring.
Inspect the current configuration with:
sbc config show # resolved values and the file they came from
sbc config path # path of the nearest sbc.config.json{
"version": 1,
"registry": "aliyun"
}Note on Boot versions. Spring Boot artifacts used a
.RELEASEsuffix before 2.4.0 (2.3.12.RELEASE) and plain semver from 2.4.0 on (2.6.13).sbcsends whichever form actually exists on Maven Central for the version you pick, so generated builds resolve their BOM on both old and new releases — regardless of which registry served the project.
Search dependencies
sbc search graphql
sbc search "spring security"
# Search the Alibaba Cloud registry instead
sbc search nacos --registry aliyunRun a project
# Run the project in the current directory
sbc run
# Run a workspace module by name, from anywhere in the workspace
sbc run my-app
# Forward extra arguments to mvnw/gradlew
sbc run my-app -- --debugMonorepo (multi-module build)
sbc create --modules generates a real build reactor, not a folder of unrelated
projects: an aggregator at the root owns the build, every module inherits from
it, and one ./mvnw / ./gradlew builds the whole tree.
# Interactive — pick "Monorepo" when asked for the layout, then add modules
sbc create shop
# Non-interactive: flat modules, all sharing --deps
sbc create shop --modules api,core,web -d web
# Nested paths and per-module dependencies
sbc create shop --modules "api:web,data-jpa;services/gateway:web;core"
# Gradle works the same way
sbc create shop --modules api,web --type gradle-projectThe result is a single reactor:
shop/
├── pom.xml # <packaging>pom</packaging> + <modules>
├── mvnw # one wrapper for the whole tree
├── sbc.workspace.json
├── api/
│ ├── pom.xml # <parent> → ../pom.xml
│ └── src/main/java/com/example/api/ApiApplication.java
├── core/
│ └── pom.xml # <parent> → ../pom.xml
└── services/gateway/
└── pom.xml # <parent> → ../../pom.xmlModules share the build tool, language, Boot version, Java version and group id;
they differ in artifact id, package and dependencies. Bump the Boot version once
in the root pom.xml and every module follows.
cd shop
./mvnw install -DskipTests # build every module
./mvnw -pl api spring-boot:run # run one module
sbc list # list modules
sbc run api # same thing, from anywhereGradle roots get settings.gradle (or .kts) with an include per module, and
module build files read their group/version from rootProject.
Workspace
A workspace is any directory with an sbc.workspace.json manifest. sbc create
maintains it for you — a monorepo writes it at its root, and standalone projects
are auto-registered in an enclosing one:
# Track independently built projects under one root
sbc workspace init
sbc create services/user-service -d web,data-jpa
sbc create apps/api-gateway --type gradle-project -d web
sbc list
sbc run user-serviceThe manifest records the aggregator (when the root is a reactor) and each module's name, path, build type, language, Boot version and parent:
{
"version": 2,
"root": { "artifactId": "shop", "type": "maven-project", "bootVersion": "4.1.1" },
"modules": [
{
"name": "api",
"path": "services/api",
"type": "maven-project",
"language": "java",
"bootVersion": "4.1.1",
"parent": "shop"
}
]
}Development
pnpm install
pnpm build # bundle to dist/ with tsup
pnpm test # unit tests (node:test)
pnpm dev # watch modeLicense
ISC © jeangrey
