@servicetitan/docs-uikit 33.1.1 → 34.0.0

package/docs/BREAKING_CHANGES.mdx

@@ -3,6 +3,14 @@ title: BREAKING CHANGES
 sidebar_position: 0
 ---
 
+## v34.0.0
+
+### [@servicetitan/startup](./startup/)
+
+- Upgraded Vitest from v3 to v4. For a complete list of breaking changes, see the [Migration Guide](https://vitest.dev/guide/migration.html).
+- Upgraded Prettier from 3.6.x to 3.7.x which includes formatting changes. Run `npx startup lint --fix` to fix new lint errors.
+- Changed startup to disallow running `mfe-publish` from a global installation because building and publishing with different versions could lead to unexpected runtime errors.
+
 ## v33.0.0
 
 ### [@servicetitan/startup](./startup/)

package/docs/folder-schema.mdx

@@ -43,20 +43,20 @@ Contains enum and types useful to create an object with files hierarchy configur
 
 Enum with all supported naming conventions.
 
--   DashDelimitedLowercase - `dash-delimited-lowercase`
--   CamelCase - `camelCase`
+- DashDelimitedLowercase - `dash-delimited-lowercase`
+- CamelCase - `camelCase`
 
 ### Folder
 
 The type for configuration any folder except the root folder.
 
--   `name` - name of the folder the configuration is for, supports `glob` syntax
--   `namingConvention?` - naming convention for all nested files and folders, subfolders inherits the value of this property
--   `children?` - configurations of allowed subfolders, an empty array by default
--   `allowedFiles?` - list of files that can be placed in this folder is used to check the full filename with an extension, doesn't support path before filename; all files are allowed by default, supports `glob` syntax
--   `allowedExtensions?` - list of files extensions that can be placed in this folder is used to check only the part that starts after the first dot; by default is equal to the value from a parent folder configuration or an empty array for the root folder, supports `glob` syntax
--   `overrideExtensions?` - if `false` parent extensions are getting concatenated with current ones, `true` by default but take effect only if `allowedExtensions` is defined
--   `ignore?` - if `true` then all content will be considered valid
+- `name` - name of the folder the configuration is for, supports `glob` syntax
+- `namingConvention?` - naming convention for all nested files and folders, subfolders inherits the value of this property
+- `children?` - configurations of allowed subfolders, an empty array by default
+- `allowedFiles?` - list of files that can be placed in this folder is used to check the full filename with an extension, doesn't support path before filename; all files are allowed by default, supports `glob` syntax
+- `allowedExtensions?` - list of files extensions that can be placed in this folder is used to check only the part that starts after the first dot; by default is equal to the value from a parent folder configuration or an empty array for the root folder, supports `glob` syntax
+- `overrideExtensions?` - if `false` parent extensions are getting concatenated with current ones, `true` by default but take effect only if `allowedExtensions` is defined
+- `ignore?` - if `true` then all content will be considered valid
 
 ### RootFolder
 

package/docs/ko-bridge.mdx

@@ -8,9 +8,9 @@ title: React-Knockout Bridge
 
 ## When to use?
 
--   When you already have a `Knockout` component that you want to show from `React`.
--   When you have `React` component you want to show from Knockout.
--   For new components we suggest to build it in `React` from scratch.
+- When you already have a `Knockout` component that you want to show from `React`.
+- When you have `React` component you want to show from Knockout.
+- For new components we suggest to build it in `React` from scratch.
 
 ## KnockoutComponent
 

package/docs/launchdarkly-service.mdx

@@ -39,7 +39,7 @@ and automatically [provides a store](#use-flags-in-mobx-store) that allows flag
 | `clientSideID`          | `string`  | The client-side ID that authorizes the client to connect to a particular LaunchDarkly project. The [getValueForEnvironment](./web-components/get-value-for-environment) helper provides a convenient way to map Monolith environments to the corresponding client-side ID. |
 | `projectName`           | `string`  | The name of the LaunchDarkly project, for logs and error messages.                                                                                                                                                                                                         |
 | `context`               | `object`  | (Optional) Context for targeting rules. Defaults to anonymous user. Use LaunchDarkly's [`identify`](https://docs.launchdarkly.com/sdk/features/identify) method to change the context after initialization.                                                                |
-| `waitForInitialization` | `boolean` | (Optional) Whether or not to wait until flags values are available before rendering children. Defaults to `true`                                                                                                                                                           |
+| `waitForInitialization` | `boolean` | (Optional) Whether or not to wait until flags values are available before rendering children. Defaults to `true`.                                                                                                                                                          |
 
 :::caution
 When a `context` is provided, only the initial value takes affect. Subsequent calls with the same client-side ID reuse the client that was created with the initial context.
@@ -127,7 +127,7 @@ Simply wrap the host with `LDServiceProvider` to ensure that it and embedded MFE
 
 ```tsx
 import { FC, StrictMode } from 'react';
-import { LogService } from '@servicetitan/launchdarkly-service';
+import { LDServiceProvider } from '@servicetitan/launchdarkly-service';
 
 export const HostApp: FC = () => {
     return(
@@ -140,6 +140,35 @@ export const HostApp: FC = () => {
 };
 ```
 
+#### Props
+
+| Name          | Type            | Description                                                            |
+| :------------ | :-------------- | :--------------------------------------------------------------------- |
+| `application` | `LDApplication` | (Optional) Application and version details to provide to LaunchDarkly. |
+
+#### LDApplication
+
+```tsx
+export interface LDApplication {
+    id?: string;
+    version?: string;
+}
+```
+
+Use `application` to make the application id and version available for flag evaluations in LaunchDarkly. Every LaunchDarkly client created by [LDProvider](#ldprovider) (within the host and within MFEs) will automatically pass through the application metadata to LaunchDarkly.
+
+:::caution
+`LDServiceProvider` should not be used in MFEs. If an MFE does use `LDServiceProvider`, the host's `application` overrides the MFE's.
+:::
+
+#### Example
+
+```tsx
+<LDServiceProvider application={{ id: 'app', version: '71' }}>
+    {...}
+</LDServiceProvider>
+```
+
 ### LDService
 
 The `LDService` interface enables [headless bundles](./microfrontends/developing/headless-bundle) to create and reuse client connections for LaunchDarkly projects.
@@ -147,11 +176,13 @@ The `LDService` interface enables [headless bundles](./microfrontends/developing
 ```ts
 export interface LDService {
     getClient: (config: ClientConfig) => LDClient;
+    application?: LDApplication;
 }
 
 export interface ClientConfig {
     clientSideID: string;
     context?: LDContext;
+    options?: LDOptions;
 }
 ```
 
@@ -159,10 +190,15 @@ export interface ClientConfig {
 
 Returns an `LDClient` instance configured with the following parameters.
 
-| Name           | Type     | Description                                                         |
-| :------------- | :------- | :------------------------------------------------------------------ |
-| `clientSideID` | `string` | The LaunchDarkly client-side ID.                                    |
-| `context`      | `object` | (Optional) Context for targeting rules. Defaults to anonymous user. |
+| Name           | Type        | Description                                                         |
+| :------------- | :---------- | :------------------------------------------------------------------ |
+| `clientSideID` | `string`    | The LaunchDarkly client-side ID.                                    |
+| `context`      | `object`    | (Optional) Context for targeting rules. Defaults to anonymous user. |
+| `options`      | `LDOptions` | (Optional) LaunchDarkly initialization options.                     |
+
+#### application
+
+Optional [LDApplication](#ldapplication) that was passed to [LDServiceProvider](#ldserviceprovider).
 
 ### FeatureFlagStore
 

package/docs/react-ioc.mdx

@@ -8,10 +8,10 @@ title: React IoC
 
 ## Features
 
--   Supports hierarchical Dependency Injection
--   Easy API that supports Singleton and Transient patterns
--   Support for decorator and JSX based injection
--   Automatic cleaning of injected properties on unmounting of React components
+- Supports hierarchical Dependency Injection
+- Easy API that supports Singleton and Transient patterns
+- Support for decorator and JSX based injection
+- Automatic cleaning of injected properties on unmounting of React components
 
 ## Examples
 

package/docs/startup/build.mdx

@@ -20,6 +20,7 @@ Build packages for production to the `dist/bundle` folders. It bundles them in p
 The `build` command executes these steps:
 
 1. Activate Kendo UI license.
+1. Run package **precompile** scripts, if any.
 1. Compile Typescript.
 1. Generate TypeScript definitions from CSS, LESS, and SASS modules, and copy assets and style files to the output folder.
 1. Run type check via [TypeScript project references](https://www.typescriptlang.org/docs/handbook/project-references.html).
@@ -29,6 +30,12 @@ The `build` command executes these steps:
 `startup` doesn't support dependencies between the Webpack bundles.
 :::
 
+### Precompile Script
+
+✨ New in **v34.0.0** ✨
+
+The `build` command runs the `precompile` script defined in each package's `package.json` before compiling TypeScript. This allows packages to execute custom setup tasks during the build process. If a package doesn't define a `precompile` script, this step is skipped.
+
 ## Package Setup
 
 Because `startup` compiles and builds in separate steps, packages must export compiled Javascript instead of the TypeScript source files. E.g.,
@@ -73,7 +80,7 @@ function MyImage() {
 }
 ```
 
-### Importing SVGs as React components
+### Importing SVGs as React Components
 
 By default `startup` imports SVGs from `@servicetitan/anvil2` as React components. E.g.,
 
@@ -97,7 +104,7 @@ export function CheckButton() {
 }
 ```
 
-### Importing Anvil 2 SVGs as assets
+### Importing Anvil 2 SVGs as Assets
 
 By default `startup` imports SVGs from `@servicetitan/anvil2` as React components.
 To import an Anvil 2 SVG as an asset, append `?asset` to the import statement. E.g.,
@@ -112,7 +119,7 @@ function CheckImage() {
 
 ## Configuration
 
-### Library packages
+### Library Packages
 
 Set `cli.webpack` to `false` to disable Webpack for non-application packages, such as component and utility libraries.
 
@@ -158,7 +165,7 @@ Use `tsconfig.build.json` that extends from `tsconfig.json` to exclude tests, st
 Project references must be duplicated in `tsconfig.build.json` because [references are not inherited](https://github.com/microsoft/TypeScript/issues/27098).
 :::
 
-### TypeScript compilation (SWC)
+### TypeScript Compilation (SWC)
 
 :::info
 `Startup` only maps a subset of TypeScript settings from `tsconfig.json` to SWC options. See [cliOptions](https://github.com/search?q=repo%3Aservicetitan%2Fuikit+%22cliOptions%3A%22+-path%3A**%2F*.test.ts&type=code) and [swcOptions](https://github.com/search?q=repo%3Aservicetitan%2Fuikit+%22swcOptions%3A%22+-path%3A**%2F*.test.ts&type=code) for the details.
@@ -182,7 +189,7 @@ Use `cli.swc-compile-package` to set or override SWC options. E.g.,
 }
 ```
 
-### TypeScript compilation (TSC)
+### TypeScript Compilation (TSC)
 
 :::caution
 Compilation via TSC is deprecated.

package/docs/startup/clean.mdx

@@ -5,8 +5,8 @@ title: clean
 Resets project workspace to a fresh state by clearing build caches and removing untracked files.
 
 It runs tools like `nx reset` and `jest --clearCache` to clear project and test
-caches, and then uses `git clean -fdX` to delete all untracked files and
-directories (such as build outputs and temporary files).
+caches, clears the npm and npx caches, and then uses `git clean -fdX` to delete
+all files ignored by Git (such as build outputs and temporary files).
 
 ```sh
 npx --yes @servicetitan/startup clean

package/docs/startup/install.mdx

@@ -4,179 +4,8 @@ title: install
 
 :::danger
 The `startup install` command is deprecated; please instead use [@servicetitan/install](../install).
+:::
 
 As `@servicetitan/startup` grew more features, it became too large for simple bootstrapping. The
 dedicated `@servicetitan/install` package performs a single task and runs quickly. And because it
 has no runtime dependencies, also eliminates risks from third-party changes.
-:::
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-Installs project dependencies.
-
-Use this command instead of plain `npm install` to guarantee that all packages are installed correctly and any necessary post-install steps are performed.
-
-```sh
-npx --yes @servicetitan/startup install
-```
-
-See [package.json in the example project](https://github.com/search?q=repo%3Aservicetitan%2Ffrontend-example+path%3A**%2Fpackage.json+%22startup+install%22&type=code) for how to use `install` in an npm script.
-
-## Options
-
-| Option       | Description                                                              |
-| :----------- | :----------------------------------------------------------------------- |
-| `--no-token` | Only install dependencies. Don't configure the npm authentication token. |
-| `--token`    | Only configure the npm authentication token. Don't install dependencies. |
-
-## Configuring NPM Token in Development
-
-In development environments, `startup install` automatically configures an npm authentication token that grants access to private ServiceTitan packages. It securely retrieves the token and updates your npm configuration so you can install dependencies without any further setup.
-
-:::tip
-If your project is using `startup` v31 or earlier, or isn't using `startup` at all, run this command to manually configure the npm authentication token.
-
-```
-npx --yes @servicetitan/startup@latest install --token
-```
-
-:::
-
-:::caution
-`startup install` detects if it is running in development by checking for standard environment variables set by CI systems (e.g.,`CI` and `TEAMCITY_VERSION`). If none of these variables are set, it assumes it is running on a developer machine.
-If it mistakes a CI environment for a developer machine, add a `CI` environment variable (with any value) to the workflow, or [use `--no-token`](#how-to-use---no-token) to disable configuring the npm token.
-:::
-
-## Configuring NPM Token in CI
-
-In CI environments such as Teamcity and Github, use the `ST_NPM_READONLY_TOKEN` organization secret to grant access to private ServiceTitan packages. You can do this in two ways:
-
-### Option 1: Inject into .npmrc (Recommended)
-
-The recommended method is to use `npm config set --location=project` to manually inject the organization secret into the project's `.npmrc`. For example,
-
-<Tabs
-defaultValue="github"
-values={[{ label: "Github Action", value: "github"}, {label: "Dockerfile", value: "docker"}]}>
-
-<TabItem value="github">
-
-```yml
-- run: npm config set --location=project "//registry.npmjs.org/:_authToken"="${{ secrets.ST_NPM_READONLY_TOKEN }}"
-- run: npm run build
-```
-
-Alternatively, in Github actions using `action/setup-node`, you can use `registry-url` and `env.NODE_AUTH_TOKEN` to have it configure the project level `.npmrc`. For example,
-
-```yml
-- uses: actions/setup-node@v4
-  registry-url: https://registry.npmjs.org
-  env:
-      NODE_AUTH_TOKEN: ${{ secrets.ST_NPM_READONLY_TOKEN }}
-```
-
-</TabItem>
-<TabItem value="docker">
-
-```dockerfile
-ARG NPM_READONLY_TOKEN
-
-RUN npm config set --location=project "//registry.npmjs.org/:_authToken=$NPM_READONLY_TOKEN"
-RUN npm run build
-```
-
-</TabItem>
-</Tabs>
-
-### Option 2: Use environment variable
-
-:::caution
-Using an environment variable is not recommended because it requires [extra steps](#how-to-configure-with-legacy-startup) to rotate the token in projects using `startup` v31 or earlier.
-:::
-
-To use an environment variable to configure the npm token, modify `.npmrc` to get the token from an environment variable,
-
-```npmrc title=".npmrc"
-//registry.npmjs.org/:_authToken=${NPM_READONLY_TOKEN}
-```
-
-Then, in the CI action, set that environment variable to the organization secret. For example,
-
-<Tabs
-defaultValue="github"
-values={[{ label: "Github Action", value: "github"}, {label: "Dockerfile", value: "docker"}]}>
-
-<TabItem value="github">
-
-```yml
-- run: npm run build
-  env:
-      NPM_READONLY_TOKEN: ${{ secrets.ST_NPM_READONLY_TOKEN }}
-```
-
-</TabItem>
-<TabItem value="docker">
-
-```dockerfile
-ARG NPM_READONLY_TOKEN
-
-ENV NPM_READONLY_TOKEN=${NPM_READONLY_TOKEN}
-
-RUN npm run build
-```
-
-</TabItem></Tabs>
-
-## How to Configure Development Environment When Not Using Startup v32 or Later {#how-to-configure-with-legacy-startup}
-
-:::note
-These instructions are only for projects using [Option 2](#option-2-use-environment-variable) with `startup` v31 or earlier (or that are not using `startup` at all);
-`startup` v32 automatically detects and provides environment variables to `npm install`.
-:::
-
-If your project is [using an environment variable](#option-2-use-environment-variable), and it isn't using `startup` v32 or later, then developers must also defined the same environment variable manually. And they must repeat these steps each time the token is rotated,
-
-1. Run `npx --yes @servicetitan/startup@latest install --token` to add the token to your per-user configuration.
-2. Run `npm config get userconfig` to get the location of your per-user configuration file.
-3. Find the token in the configuration file, on the line that starts `//registry.npmjs.org/:_authToken=`
-4. Create a local environment variable with the token. Use the same variable name as in project's `.npmrc`.
-
-:::tip
-On MacOS you can accomplish steps 2 and 3 with this single command:
-
-```sh
-grep registry.npmjs.org < $(npm config get userconfig)
-```
-
-:::
-
-## How to Use --no-token
-
-If startup mistakes your CI environment for a development machine and it isn't practical to add a `CI` environment variable to the workflow, use `--no-token` to instruct `startup install` not to attempt to configure the npm token.
-
-Create a `build:ci` script and accompanying pre script that runs `bootstrap` with `-- --no-token`:
-
-```json title="package.json"
-    "scripts": {
-        "prebuild:ci": "npm run bootstrap -- --no-token",
-        "build:ci": "startup build"
-    },
-```
-
-Then, call `build:ci` instead of `build` in the CI workflow:
-
-```sh
-npm run build:ci
-```
-
-:::note
-This assumes you're using this recommended `bootstrap` script:
-
-```json
-    "scripts": {
-        "bootstrap": "npx --yes @servicetitan/startup install",
-    }
-```
-
-:::

package/docs/startup/mfe-check.mdx

@@ -0,0 +1,150 @@
+---
+title: mfe-check
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+Checks MFE/host dependency compatibility.
+
+Use `mfe-check` to verify that an MFE's shared dependencies are compatible with the host application. This determines whether the MFE can use a "light" or "full" bundle (see [Sharing Dependencies](../microfrontends/sharing-dependencies)).
+
+:::caution
+The host must be configured to [expose shared dependencies](../microfrontends/hosting#configuration) else `mfe-check` exits with an error.
+:::
+
+## Options
+
+| Option                | Description                                                                                                                          |
+| :-------------------- | :----------------------------------------------------------------------------------------------------------------------------------- |
+| `--metadata`          | Path to MFE's `metadata.json` file, can be generated with the [`mfe-generate-metadata`](./mfe-generate-metadata) command (required). |
+| `--host-package-json` | Path to host `package.json` file (required). Can be specified multiple times.                                                        |
+| `--json`              | Output results as JSON instead of human-readable format. Default: `false`.                                                           |
+
+## Usage
+
+<Tabs>
+  <TabItem value="basic" label="Basic" default>
+
+Run the `mfe-check` command to check compatibility with an MFE:
+
+```sh
+npx startup mfe-check \
+  --metadata path/to/mfe/metadata.json \
+  --host-package-json path/to/host/package.json
+```
+
+  </TabItem>
+  <TabItem value="monorepo" label="Monorepo">
+
+For monorepos with dependencies split across multiple `package.json` files, specify each one:
+
+```sh
+npx startup mfe-check \
+  --metadata path/to/mfe/metadata.json \
+  --host-package-json path/to/host/app/package.json \
+  --host-package-json path/to/host/root/package.json
+```
+
+:::caution
+The first `--host-package-json` must be the host package's own `package.json`. This is the file from which the command reads the [`expose-shared-dependencies`](../microfrontends/hosting#configuration) (and [`shared-dependencies`](../microfrontends/sharing-dependencies)) configuration. Dependencies are merged from all specified files, with the first file's versions taking precedence.
+:::
+
+  </TabItem>
+
+</Tabs>
+
+When the MFE and host have compatible dependencies, `mfe-check` exits with a zero status code. If they are incompatible, or there is an unexpected error, it exits with a non-zero status code.
+
+## Output
+
+<Tabs>
+  <TabItem value="compatible" label="Compatible" default>
+
+When all shared dependencies match, the light bundle of the MFE can be loaded:
+
+```
+Checking @servicetitan/my-mfe...
+Compatible: light bundle can be used
+```
+
+  </TabItem>
+  <TabItem value="mismatch" label="Version mismatch">
+
+When dependency versions don't match, it lists the mismatched dependencies:
+
+```
+Checking @servicetitan/my-mfe...
+Dependency mismatch found:
+  react: host=18.2.0, package=^17.0.0
+  mobx: host=missing, package=^6.0.0
+Result: full bundle required
+```
+
+  </TabItem>
+  <TabItem value="shared-dependencies-not-exposed" label="Shared dependencies not exposed">
+
+When the host does not expose dependencies, it reports the error:
+
+```
+Checking @servicetitan/my-mfe...
+expose-shared-dependencies is not enabled in host package.json
+Result: full bundle required
+```
+
+  </TabItem>
+</Tabs>
+
+### JSON Output
+
+<Tabs>
+  <TabItem value="json-compatible" label="Compatible" default>
+
+```json
+{
+    "name": "@servicetitan/my-mfe",
+    "compatible": true,
+    "bundleType": "light",
+    "isSharedDependenciesEnabled": true,
+    "isHostMfe": false
+}
+```
+
+  </TabItem>
+  <TabItem value="json-mismatch" label="Version Mismatch">
+
+```json
+{
+    "name": "@servicetitan/my-mfe",
+    "compatible": false,
+    "bundleType": "full",
+    "isSharedDependenciesEnabled": true,
+    "isHostMfe": false,
+    "mismatches": {
+        "react": { "host": "18.2.0", "package": "^17.0.0" },
+        "mobx": { "host": "missing", "package": "^6.0.0" }
+    }
+}
+```
+
+  </TabItem>
+  <TabItem value="shared-dependencies-not-exposed" label="Shared dependencies not exposed">
+
+```json
+{
+    "name": "@servicetitan/my-mfe",
+    "compatible": false,
+    "bundleType": "full",
+    "isSharedDependenciesEnabled": false,
+    "isHostMfe": false
+}
+```
+
+  </TabItem>
+</Tabs>
+
+## See Also
+
+- [`mfe-generate-metadata`](./mfe-generate-metadata) - Generate MFE metadata for compatibility checking
+- [Sharing Dependencies](../microfrontends/sharing-dependencies) - Learn about shared dependencies
+- [Frontend Example](https://github.com/servicetitan/frontend-example/blob/master/.github/workflows/mfe-check-shared-dependencies-trigger.yml) - Example workflow that automates compatibility check

package/docs/startup/mfe-generate-metadata.mdx

@@ -0,0 +1,26 @@
+---
+title: mfe-generate-metadata
+---
+
+Generates MFE metadata for compatibility checking.
+
+Use `mfe-generate-metadata` to produce a `metadata.json` file containing information about the MFE's shared dependencies, bundled versions, and entrypoints. This metadata is used by the [`mfe-check`](./mfe-check) command to check compatibility between an MFE and a host application.
+
+:::note
+This command must be run from within an MFE directory.
+:::
+
+```sh
+npx startup mfe-generate-metadata --output metadata.json
+```
+
+## Options
+
+| Option     | Description                                                        |
+| :--------- | :----------------------------------------------------------------- |
+| `--output` | Output file path. If not specified, metadata is written to stdout. |
+
+## See Also
+
+- [`mfe-check`](./mfe-check) - Check MFE/host dependency compatibility
+- [Sharing Dependencies](../microfrontends/sharing-dependencies) - Learn about shared dependencies

package/docs/startup/mfe-publish.mdx

@@ -2,7 +2,7 @@
 title: mfe-publish
 ---
 
-This is an umbrella command for both publishing and unpublishing (cleaning up) MFEs. This command allows publishing MFEs in a way that there is no risk of colliding package versions (a common issue with back-merging). See the `--build` option for more details.
+This is an umbrella command for publishing, unpublishing (cleaning up), and rolling back MFEs. This command allows publishing MFEs in a way that there is no risk of colliding package versions (a common issue with back-merging). See the `--build` option for more details.
 
 ## Publishing options
 
@@ -29,6 +29,17 @@ Do not use the `@latest` tag for production deployments because it could be assi
 | `--count <number>` | The number of package versions to keep (e.g., if twelve versions are published, `--count 10` removes the two oldest). The default value is 5. |
 | `--dry`            | Log what the command would do without actually unpublishing anything.                                                                         |
 
+## Rollback options
+
+✨ New in **v34.0.0** ✨
+
+| Option             | Description                                                                                                                                                    |
+| :----------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `--rollback`       | Instructs `mfe-publish` to rollback a tagged version to its previous version instead of publishing.                                                            |
+| `--tag <string>`   | **Required when using `--rollback`**. The tag to rollback to its previous version. The command will look for a rollback version with the suffix `-rollback-1`. |
+| `--scope <string>` | Specify one or more packages to rollback. Can be used multiple times: `--scope pkg1 --scope pkg2`.                                                             |
+| `--dry`            | Log what the command would do without actually performing the rollback.                                                                                        |
+
 ## Branch configs
 
 ✨ New in **v28.1.1** ✨

package/docs/startup/review.mdx

@@ -556,6 +556,46 @@ To manually hoist packages to the root `node_modules`:
 
 ---
 
+### require-tsconfig-references
+
+Ensures that TypeScript project references are configured for all local workspace dependencies.
+
+When a package depends on another package in the workspace, the `tsconfig.json` (and any config that extends it, such as `tsconfig.build.json`) should include a reference to that dependency's tsconfig. This enables incremental builds and ensures proper type checking across package boundaries.
+
+#### ✅ Autofix
+
+This rule supports autofix.
+It adds missing references to both the main tsconfig and any extended configs. For example, given:
+
+```json title="packages/my-package/package.json"
+{
+    "dependencies": {
+        "common": "1.0.0"
+    }
+}
+```
+
+And,
+
+```json title="packages/my-package/tsconfig.json"
+{
+    "compilerOptions": { ... }
+}
+```
+
+It updates the tsconfig to:
+
+```json title="packages/my-package/tsconfig.json"
+{
+    "compilerOptions": { ... },
+    "references": [
+        { "path": "../common/tsconfig.json" }
+    ]
+}
+```
+
+---
+
 ### require-servicetitan-scope
 
 Checks that public packages are scoped to the `@servicetitan` namespace.

package/docs/startup/start.mdx

@@ -22,7 +22,7 @@ npx -yes http-server packages/application/dist/bundle
 | `--code-coverage` | Add [instrumentation](https://github.com/JS-DevTools/coverage-istanbul-loader) to bundled code in order to collect code coverage |
 | `--use-tsc`       | Use TSC for TypeScript compilation                                                                                               |
 
-## Start steps
+## Start Steps
 
 The `start` command executes the same steps as the `build` command, then watches for changes and automatically reruns each step as needed.
 

package/docs/startup/startup.mdx

@@ -29,6 +29,8 @@ Updating build tooling is typically a daunting and time-consuming task. When new
 - [install](./install) install project dependencies
 - [kendo-ui-license](./kendo-ui-license) install KendoReact license key
 - [lint](./lint) run eslint and stylelint
+- [mfe-check](./mfe-check) check MFE/host dependency compatibility
+- [mfe-generate-metadata](./mfe-generate-metadata) generate MFE metadata for compatibility checking
 - [mfe-list](./mfe-list) list published MFE packages
 - [mfe-publish](./mfe-publish) publish or unpublish MFE packages
 - [review](./review) check project for configuration errors

package/docs/web-components/use-mfe-data-context.mdx

@@ -2,7 +2,7 @@
 title: useMFEDataContext
 ---
 
-If data is provided to an MFE via `<Loader>`, the  data can be accessed within the MFE using the `useMFEDataContext` hook. You must provide the type of the data you expect to receive.
+If data is provided to an MFE via `<Loader>`, the data can be accessed within the MFE using the `useMFEDataContext` hook. You must provide the type of the data you expect to receive.
 
 ```tsx
 import { useMFEDataContext } from '@servicetitan/web-components';

package/package.json

@@ -1,7 +1,7 @@
 {
     "name": "@servicetitan/docs-uikit",
-    "version": "33.1.1",
-    "description": "",
+    "version": "34.0.0",
+    "description": "Documentation content for Uikit packages published at docs.st.dev",
     "repository": {
         "type": "git",
         "url": "https://github.com/servicetitan/uikit.git",
@@ -16,5 +16,5 @@
     "cli": {
         "webpack": false
     },
-    "gitHead": "36ff4078b07d6c86bdf968b7f8b3c0adbe03fd4c"
+    "gitHead": "e193dc22703963f67099874a24de535d0696b6e2"
 }