You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Flip docs default to released + support doc-only releases (#177)
* Flip docs default to released + support doc-only releases
Add a private @salesforce/b2c-dx-docs workspace package to enable:
- Doc-only releases via changesets without bumping CLI/SDK/MCP versions
- Automatic docs rebuild when SDK changes (via updateInternalDependencies cascade)
- Changelog tracking for documentation changes
Flip the docs deployment so released/stable docs are served at the root
URL and dev docs live at /dev/. Previously dev was at root and released
docs were at /release/.
Update deploy-docs workflow to build stable docs at root from the latest
tag (matching both @salesforce/* and docs@* patterns) and nest dev docs
under /dev/. Update publish workflow to create docs@<version> tags and
trigger docs deployment on stable releases.
* Update AGENTS.md with docs workspace package details
Document the docs workspace package in the monorepo package listing,
Documentation section (build modes, URL structure, doc-only releases,
SDK cascade), and Changesets section.
* Add docs CI workflow to verify docs build on PRs
Runs on PRs that touch docs/ or SDK source (which affects TypeDoc API
docs generation). Catches broken docs builds before merge.
* Move docs build check into main CI workflow
Add a docs build step to ci.yml after package builds instead of a
separate docs-ci workflow. Reuses the existing checkout, install, and
build steps — more efficient than spinning up a separate runner.
* Move docs build deps and config into docs workspace package
Move vitepress, typedoc, and typedoc plugins from root devDependencies
into docs/package.json. Move typedoc.json into docs/ with adjusted
relative paths. Root package.json scripts now proxy to the docs package
via pnpm --filter.
* List docs as valid changeset package and start at 0.1.0
Add explicit list of valid changeset packages to AGENTS.md and note
doc-only changeset guidance. Set docs package version to 0.1.0 to
align with the pre-GA versioning of the other packages.
Copy file name to clipboardExpand all lines: AGENTS.md
+32-4Lines changed: 32 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,7 @@ This is a monorepo project with the following packages:
4
4
-`./packages/b2c-cli` - the command line interface built with oclif
5
5
-`./packages/b2c-tooling-sdk` - the SDK/library for B2C Commerce operations; supports the CLI and can be used standalone
6
6
-`./packages/b2c-dx-mcp` - Model Context Protocol server; also built with oclif
7
+
-`./docs` - documentation site (private `@salesforce/b2c-dx-docs` workspace package; not published to npm)
7
8
8
9
## Common Commands
9
10
@@ -97,10 +98,33 @@ See [documentation skill](./.claude/skills/documentation/SKILL.md) for details o
97
98
# Run docs dev server (from project root)
98
99
pnpm run docs:dev
99
100
100
-
# Build docs for production
101
+
# Build docs for production (stable mode — root base path)
101
102
pnpm run docs:build
103
+
104
+
# Build docs in dev mode (/dev/ base path)
105
+
IS_DEV_BUILD=true pnpm run docs:build
106
+
```
107
+
108
+
### Docs workspace package
109
+
110
+
The `./docs` directory is a private workspace package (`@salesforce/b2c-dx-docs`) with a dependency on `@salesforce/b2c-tooling-sdk`. This exists to support doc-only releases and changelog tracking via changesets, not for npm publishing. It has no build script — `pnpm -r run build` skips it.
111
+
112
+
**Deployed URL structure:** stable/released docs are served at the root URL, dev docs (from `main`) live at `/dev/`.
113
+
114
+
**Doc-only releases:** to release documentation changes without bumping CLI/SDK/MCP, create a changeset that targets only the docs package:
115
+
116
+
```md
117
+
---
118
+
'@salesforce/b2c-dx-docs': patch
119
+
---
120
+
121
+
Improved authentication guide with step-by-step examples
102
122
```
103
123
124
+
This produces a `docs@<version>` tag and triggers a docs rebuild on merge of the version PR.
125
+
126
+
**Automatic cascade:** because the docs package depends on the SDK, when the SDK version is bumped by a changeset, `updateInternalDependencies: "patch"` auto-bumps the docs version too — triggering a docs rebuild (correct since API docs are generated from the SDK).
127
+
104
128
## Logging
105
129
106
130
- when logging use the logger instance from `@salesforce/b2c-tooling-sdk/logger` package
@@ -142,8 +166,9 @@ This project uses [Changesets](https://github.com/changesets/changesets) for ver
142
166
143
167
**How it works:**
144
168
- A changeset affecting only the SDK bumps only the SDK version
145
-
- Packages that depend on a bumped package get an automatic patch bump (via `updateInternalDependencies: "patch"`) — e.g., if SDK bumps, CLI and MCP auto-get a patch bump because they depend on it
146
-
- Only packages with a newer version than what's on npm get published
169
+
- Packages that depend on a bumped package get an automatic patch bump (via `updateInternalDependencies: "patch"`) — e.g., if SDK bumps, CLI, MCP, and Docs all auto-get a patch bump
170
+
- Only packages with a newer version than what's on npm get published (docs package is private and uses git tags instead)
171
+
- A changeset targeting only `@salesforce/b2c-dx-docs` triggers a doc-only release — no npm packages are published, just a `docs@<version>` tag and docs rebuild
147
172
148
173
Changeset guidelines:
149
174
- Create a changeset for any user-facing changes (features, bug fixes); typically in new pull requests
@@ -157,7 +182,9 @@ Changeset guidelines:
157
182
- HOW a consumer should update their code
158
183
- Good changesets are brief and user-focused (not contributor); they are generally 1 line or two; The content of the changeset is used in CHANGELOG and release notes. You do not need to list internal implementation details or all details of commands; just the high level summary for users.
159
184
160
-
create a changeset file directly in `.changeset/` with a unique filename (e.g., `descriptive-change-name.md`):
0 commit comments