Updating BCP Framework

BCP includes a project updater that can move an existing application to a newer published framework version and refresh the active package-manager lockfile.

First update from 0.1.9 or older

BCP versions published before the updater do not know the update command. Run the newest CLI explicitly once:

npx @chidchanun/bcp@latest update

The updater adds this project script when the application does not already define its own update script:

{
  "scripts": {
    "update": "bcp update"
  }
}

Normal future updates can therefore use either:

bcp update

or, without a global BCP installation:

npm run update

Update to latest

bcp update

This resolves @chidchanun/bcp@latest from npm, pins that exact resolved release in package.json, detects the project's package manager and runs its install command.

For example, if latest resolves to 0.1.10, a generated application becomes:

{
  "dependencies": {
    "bcp": "npm:@chidchanun/[email protected]"
  }
}

The exact pin is intentional. A later plain npm install should not silently move the framework to a release that the BCP updater did not explicitly resolve.

Generated applications use the dependency key bcp with an npm alias to @chidchanun/bcp. The updater also recognizes a direct @chidchanun/bcp dependency.

Update to a specific version or dist-tag

bcp update 0.1.10
bcp update next

The target may be an exact published version or an npm dist-tag. The updater always records the exact version that the registry resolves.

Check without changing files

bcp update --check

The command resolves the current latest target and prints the installed/declaration state without modifying package.json or the lockfile.

Dry run

bcp update 0.1.10 --dry-run

A dry run resolves the target and shows the dependency/script changes without writing files or installing packages.

Project root

Use --root when updating a project from another directory:

bcp update --root ./apps/admin

Package-manager detection

BCP detects the package manager from its lockfile:

• package-lock.json -> npm
• pnpm-lock.yaml -> pnpm
• yarn.lock -> Yarn
• bun.lock / bun.lockb -> Bun

If no lockfile exists, BCP uses the invoking package-manager user agent when available and otherwise falls back to npm. If lockfiles from multiple package managers are present, the updater stops instead of guessing.

Registry version discovery currently uses npm's registry CLI (npm view) even when the project itself installs dependencies with pnpm, Yarn or Bun.

Failure safety

Before installation BCP keeps the original package.json and detected lockfile in memory. If the package-manager install fails, those files are restored before the command exits with an error.

A package manager may still have touched node_modules before failing, so run the normal install command again after resolving the underlying package-manager or network problem.

What the updater changes

The updater changes the framework dependency, adds scripts.update = "bcp update" when no update script exists, and refreshes the package-manager lockfile. An existing custom update script is never overwritten.

It does not overwrite application source code, environment files, authentication implementations, database schemas or custom configuration.

Features that were originally generator presets, such as JWT auth scaffolding, are not automatically injected into an existing application merely by updating the framework package.

Recommended verification

After an update, run the checks used by your project, for example:

npm run typecheck
npm run build

Commit package.json and the lockfile together after verification.

Release channels

Stable BCP releases use the npm latest dist-tag. A release maintainer can still publish an explicit pre-release channel with BCP_DIST_TAG, for example BCP_DIST_TAG=next.