@servicetitan/docs-uikit 22.11.0

package/README.md

@@ -0,0 +1,48 @@
+# `@servicetitan/docs-uikit`
+
+This package contains documentation for Frontend Platform packages that is hosted at https://docs.st.dev.
+
+## Preview changes locally
+
+Use the `yalc` package to preview changes before they are published:
+
+1. Install the `yalc` package globally
+
+```
+$ npm i yalc -g
+```
+
+2. Build the `uikit` packages
+
+```
+$ cd <path-to-uikit>
+$ npm run build
+```
+
+3. Run `yalc publish` in the `docs` package folder
+
+```
+$ cd .\packages\docs\
+$ yalc publish
+```
+
+4. Run `yalc add @servicetitan/docs-uikit` in ServiceTitan Engineering `docs` project, which will cause it to use the location version of the `@servicetitan/docs-uikit` package
+
+```
+$ cd <path-to-your-servicetitan-docs>
+$ yalc add @servicetitan/docs-uikit
+```
+
+5. Update your dependencies
+
+```
+$ npm i
+```
+
+6. Start the local Docusaurus server
+
+```
+$ npm start
+```
+
+This opens the documentation in a browser window. Changes are reflected live without having to restart the server.

package/docs/component-usage.mdx

@@ -0,0 +1,64 @@
+---
+title: Component Usage
+---
+
+`@servicetitan/component-usage` will calculate and publish metrics on the app's component usage. The packages which we report on are currently hard-coded to [this list](https://github.com/servicetitan/uikit/blob/master/packages/component-usage/src/index.ts#L40-L64)
+
+## Usage
+
+### Basic Usage
+
+```
+$ npm install --save-dev @servicetitan/component-usage
+$ npx component-usage
+```
+
+Or for one-time use with no installation:
+
+```
+$ npx @servicetitan/component-usage
+```
+
+### Options
+
+You must specify at least one "mode" option: `--sendToDataDog`, `--outputDir`, `--teamCityOutput`.
+
+The examples below show the long form of each option (like `--sendToDataDog`), but short forms are available (like `-s`). To see all the long and short options, use `--help`.
+
+Display help:
+
+```
+$ npx @servicetitan/component-usage --help
+```
+
+Generate stats files locally in the current directory:
+
+```
+$ npx @servicetitan/component-usage --outputDir .
+```
+
+Send metrics to DataDog:
+
+```
+$ npx @servicetitan/component-usage --sendToDataDog --dataDogApiKey ...API_KEY_GOES_HERE... --dataDogApplicationKey ...APP_KEY_GOES_HERE...
+```
+
+Porque no los dos?
+
+```
+$ npx @servicetitan/component-usage --outputDir . --sendToDataDog --dataDogApiKey ...API_KEY_GOES_HERE... --dataDogApplicationKey ...APP_KEY_GOES_HERE...
+```
+
+TeamCity output
+
+```
+$ npx @servicetitan/component-usage --teamCityOutput
+```
+
+## Live Data
+
+We currently have a [TeamCity build that triggers with every merge to master](https://teamcity.st.dev/viewType.html?buildTypeId=FrontendPlatform_ComponentUsageMaster) which specifies all three mode options:
+
+-   `--sendToDataDog`: publish the metric `far.componentUsage` to DataDog. [This DataDog dashboard](https://app.datadoghq.com/dashboard/my4-ftr-xgu/front-end-component-usage?from_ts=1602016753361&live=true&to_ts=1602103153361) shows some charts on this metric.
+-   `--outputDir`: write the stats out as files during the build, which is then published as a build artifact. [Example artifacts from a recent build](https://teamcity.st.dev/repository/download/FrontendPlatform_ComponentUsageMaster/901050:id/treemap/index.html)
+-   `--teamCityOutput`: write out special output during the TeamCity build process (like `##teamcity[buildStatisticValue...`) which gets captured and published as a TeamCity build statistic. See the [build statistics tab](https://teamcity.st.dev/viewType.html?buildTypeId=FrontendPlatform_ComponentUsageMaster&tab=buildTypeStatistics) for charts.

package/docs/error-boundary.mdx

@@ -0,0 +1,44 @@
+---
+title: Error Boundary
+---
+
+`@servicetitan/error-boundary` is an implementation of React error boundary mechanism. More info about error boundaries can be found in React [docs](https://reactjs.org/docs/error-boundaries.html).
+
+## Usage
+
+```tsx
+import { ErrorBoundary, FallbackProps } from '@servicetitan/error-boundary';
+import { Button } from '@servicetitan/design-system';
+
+const App: React.FC = () => {
+    <ErrorBoundary fallback={Fallback} moduleName="appRoot">
+        <Broken />
+    </ErrorBoundary>;
+};
+
+const Broken: React.FC = () => {
+    throw new Error('I am broken.');
+};
+
+const Fallback: React.FC<FallbackProps> = ({ onRefresh }) => {
+    return (
+        <div>
+            <span>Something went totally wrong</span>
+            <Button onClick={onRefresh}>Refresh</Button>
+        </div>
+    );
+};
+```
+
+## Package contents
+
+### ErrorBoundary
+
+React Component. It tries to catch and log errors from children.
+
+#### Props
+
+|     Name     |                      Type                      |               Description                |                               Required                                |
+| :----------: | :--------------------------------------------: | :--------------------------------------: | :-------------------------------------------------------------------: |
+| `moduleName` |                    `string`                    |       Used for log categorization        |                                  Yes                                  |
+|  `fallback`  | `React.ComponentType<{onRefresh?:() => void}>` | Component to render when error is caught | No, `ErrorBoundary` renders "Something went wrong..." text by default |

package/docs/eslint-config.mdx

@@ -0,0 +1,33 @@
+---
+title: ESLint & Stylelint configurations
+---
+
+`@servicetitan/eslint-config` and `@servicetitan/stylelint-config` packages contain core lint rule sets which should be used in ServiceTitan web projects.
+
+## Usage
+
+### ESLint
+
+#### In the Lerna project
+
+```json title=".eslintrc.json"
+{
+    "extends": ["@servicetitan/eslint-config/mono"]
+}
+```
+
+#### Without Lerna
+
+```json title=".eslintrc.json"
+{
+    "extends": ["@servicetitan/eslint-config/single"]
+}
+```
+
+### Stylelint
+
+```json title=".stylelintrc.json"
+{
+    "extends": ["@servicetitan/stylelint-config"]
+}
+```

package/docs/folder-schema.mdx

@@ -0,0 +1,204 @@
+---
+title: Folder Schema
+---
+
+Folder schema is a flexible tool to configure a strict hierarchy of files in your project with verification by `eslint`. It consists of `@servicetitan/eslint-plugin-folder-schema` and `@servicetitan/folder-lint` packages.
+
+## @servicetitan/eslint-plugin-folder-schema
+
+Contains `@servicetitan/folder-schema/check` rule with the next options:
+
+-   `root` - entry point to start recursive checking
+-   `config` - object with a configuration of files hierarchy
+-   `docLink?` - link to a document describing a required files hierarchy
+
+## @servicetitan/folder-lint
+
+Contains enum and types useful to create an object with files hierarchy configuration.
+
+### NamingConvention
+
+Enum with all supported naming conventions.
+
+-   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
+
+### RootFolder
+
+The type for root folder configuration, has the same properties as the `Folder`, but `namingConvention` is required and `name` will not be used, so you can put everything there.
+
+### Configuration example
+
+```ts
+const jest: Folder[] = [
+    {
+        name: '__mocks__',
+        children: { name: '*' },
+        allowedExtensions: '.*',
+    },
+    {
+        name: '__tests__',
+        children: { name: '*' },
+        allowedExtensions: ['.test.@(ts|tsx)', '.store.test.ts'],
+    },
+];
+
+const byFileType: Folder[] = [
+    {
+        name: 'stores',
+        allowedExtensions: '.store.ts',
+        children: [...jest, { name: '*', children: jest }],
+    },
+    {
+        name: 'utils',
+        allowedExtensions: '.ts',
+        children: [...jest, { name: '*', children: jest }],
+    },
+    {
+        name: 'components',
+        allowedExtensions: ['.tsx', '.less', '.less.d.ts'],
+        children: [...jest, { name: '*', children: jest }],
+    },
+    {
+        name: 'api',
+        allowedExtensions: '.api.ts',
+        children: jest,
+    },
+    {
+        name: 'styles',
+        allowedExtensions: ['.less', '.less.d.ts', '.css'],
+    },
+    {
+        name: 'enums',
+        allowedExtensions: ['.ts'],
+    },
+    {
+        name: 'assets',
+        allowedExtensions: ['.png', '.svg'],
+    },
+];
+
+const admin: Folder = {
+    name: 'admin',
+    children: {
+        name: 'app',
+        allowedFiles: [
+            'api-config.ts',
+            'app.tsx',
+            'global-inject.ts',
+            'index.ejs',
+            'index.tsx',
+            'routes.tsx',
+            'shared-react-init.ts',
+            'suppress-context-warnings.ts',
+            'suppress-lifecycle-warnings.ts',
+            'vendor-style.css',
+        ],
+        allowedExtensions: '.*',
+        children: [
+            {
+                name: 'modules',
+                allowedFiles: [],
+                children: [
+                    {
+                        name: 'common',
+                        children: byFileType,
+                    },
+                    {
+                        name: '*', // module level
+                        allowedFiles: [],
+                        children: [
+                            ...byFileType,
+                            {
+                                name: '*', // section level
+                                allowedFiles: [],
+                                children: [
+                                    ...byFileType,
+                                    {
+                                        name: '*', // page level
+                                        allowedFiles: [],
+                                        children: byFileType,
+                                    },
+                                ],
+                            },
+                        ],
+                    },
+                ],
+            },
+        ],
+    },
+};
+
+const desktop: Folder = {
+    name: 'desktop',
+    children: {
+        name: 'app',
+        allowedFiles: [
+            'custom.d.ts',
+            'global-inject.ts',
+            'hash-browser-router.tsx',
+            'index.ejs',
+            'index.less',
+            'index.less.d.ts',
+            'index.tsx',
+            'main-app.tsx',
+            'provider.tsx',
+            'routes.tsx',
+            'shared-react-import.ts',
+            'shared-react-init.ts',
+            'suppress-context-warnings.ts',
+            'suppress-lifecycle-warnings.ts',
+            'suspension-routing-hook.ts',
+            'vendor-style.css',
+        ],
+        allowedExtensions: '.*',
+        children: {
+            name: 'modules',
+            allowedFiles: [],
+            children: [
+                { name: 'settings', children: byFileType },
+                {
+                    name: '*', // module level
+                    allowedFiles: ['shared-react-components.ts', 'custom-notifications.ts'],
+                    children: [
+                        ...byFileType,
+                        {
+                            name: '*', // section level
+                            allowedFiles: [],
+                            children: [
+                                ...byFileType,
+                                {
+                                    name: '*', // page level
+                                    allowedFiles: [],
+                                    children: byFileType,
+                                },
+                            ],
+                        },
+                    ],
+                },
+            ],
+        },
+    },
+};
+
+const config: RootFolder = {
+    name: '<root>',
+    namingConvention: NamingConvention.DashDelimitedLowercase,
+    children: {
+        name: 'packages',
+        children: [admin, desktop],
+    },
+};
+```

package/docs/ko-bridge.mdx

@@ -0,0 +1,124 @@
+---
+title: React-Knockout Bridge
+---
+
+`@servicetitan/ko-bridge` is a collection of components and utils to connect `Knockout` and `React` codebase.
+
+## 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.
+
+## KnockoutComponent
+
+It's useful when you need to show `Knockout` component from `React` codebase.
+
+### Props
+
+```tsx
+interface KnockoutComponentProps {
+    /** The knockout model that is bound to the component */
+    koModel: any;
+    /** The html template with knockout bindings to be rendered in react */
+    koTemplate: ReturnType<typeof React.forwardRef>;
+    /** If set to true, it will allow the change in reference for the knockout model */
+    dangerouslyUpdatable?: boolean;
+}
+```
+
+_`dangerouslyUpdatable` is dangerous because change in reference might try to update the knockout html comments which will not exist in current context of react._
+
+### Examples
+
+#### Usage by extension
+
+```tsx
+class ExampleKnockoutComponent extends KnockoutComponent {
+    // if needed
+    componentDidMount() {
+        super.componentDidMount();
+    }
+
+    render() {
+        return <div data-bind="visible: window.IsExampleVisible">Invisible Example.</div>;
+    }
+}
+```
+
+#### Usage as JSX element
+
+```tsx
+const ExampleTemplate = () => <div data-bind="visible: IsExampleVisible">Invisible Example</div>;
+
+interface ExampleKnockoutComponentProps {
+    IsExampleVisible: boolean;
+}
+
+class ExampleKnockoutComponent extends React.Component<ExampleKnockoutComponentProps> {
+    render() {
+        return <KnockoutComponent koModel={this.props} koTemplate={ExampleTemplate} />;
+    }
+}
+```
+
+## HtmlComment
+
+JSX wrapper for the native comments.
+
+### Props
+
+```tsx
+interface HtmlCommentProps {
+    text: string;
+    isInTable?: boolean;
+    parent?: string;
+}
+```
+
+### Examples
+
+```tsx
+<HtmlComment text="ko if: !isAuthenticated" />
+<button
+    className="Button Button--grey Button--solid Button--small"
+    data-bind="click: function() { login(); }"
+>
+    Login
+</button>
+<HtmlComment text="/ko" />
+```
+
+## Knockout Bindings
+
+Any created `React` component can be rendered in `Knockout` to avoid code duplication, we have knockout bindings for this. `React` will render component in element with binding.
+
+_The component must be accessible anywhere, e.g. you can assign it to a `sharedReactComponent` object available in the `window`._
+
+### reactUncontrolled
+
+```tsx
+<div data-bind="reactUncontrolled: window.sharedReactComponent.ExampleKnockoutComponent" />
+```
+
+### react
+
+```tsx
+<div
+    data-bind="react: window.sharedReactComponent.ExampleKnockoutComponent, props: {
+        message: 'Hello world!'
+    }"
+/>
+```
+
+## @koObservableToMobx
+
+Sometimes in `React` codebase, you may need to use some of existing `Knockout` observables and be informed about all their changes.
+
+```tsx
+@injectable()
+class Store {
+    @koObservableToMobx(() => window.App.isAuthenticated)
+    isAuthenticated!: boolean;
+}
+```

package/docs/lazy-module.mdx

@@ -0,0 +1,53 @@
+---
+title: Lazy Module
+---
+
+In the terminology of our desktop frontend "module" is an independent business area of the application with ownership by some squad, for example, we have accounting, memberships, reporting, dispatch and other very important modules that desktop SPA consists of. Clearly, when ST users are opening desktop app they don't need all those modules loaded right away because typically they use a subset of app functionality to perform their job duties.
+
+`@servicetitan/lazy-module` is a wrapper around React Suspense mechanism to enable module-level code splitting for better web page loading performance.
+
+## Usage
+
+```tsx
+import React from 'react';
+import { lazyModule } from '@servicetitan/lazy-module';
+
+const loader = async () => {
+    const { Dispatch } = await import(
+        /* webpackChunkName: "dispatch" */
+        './dispatch'
+    );
+
+    return Dispatch;
+};
+
+// Don't create lazy module in React component render function
+// to avoid it from being re-created every re-render
+const LazyDispatch = lazyModule({ loader, name: 'Dispatch' });
+
+export const DispatchModule: React.FC = () => <LazyDispatch />;
+```
+
+## Package contents
+
+### lazyModule
+
+`lazyModule` accepts module loader function and returns React component that retrieves module from a remote host during the first render. Additionally `lazyModule` creates an [error boundary](/docs/frontend/error-boundary) around your module to catch and log runtime errors.
+
+#### Options
+
+|           Name           |                   Type                    |                            Description                             |                            Required                            |
+| :----------------------: | :---------------------------------------: | :----------------------------------------------------------------: | :------------------------------------------------------------: |
+|         `loader`         | `() => Promise<React.ComponentType<any>>` |             Function doing dynamic import of a module              |                              Yes                               |
+|          `name`          |                 `string`                  |                            Module name                             |                              Yes                               |
+|    `loadingComponent`    |        `React.ComponentType<any>`         |          Component to diplay while loading is in progress          |                No, defaults to `DefaultLoading`                |
+| `loadingErrorComponent`  |        `React.ComponentType<any>`         |            Component to display if module loading fails            |             No, defaults to `DefaultLoadingError`              |
+| `errorFallbackComponent` |        `React.ComponentType<any>`         | Component to pass to `@servicetitan/error-boundary` module wrapper | No, uses default component from `@servicetitan/error-boundary` |
+
+### DefaultLoading
+
+React Component, displays `Loading...` text.
+
+### DefaultLoadingError
+
+React Component, displays `Cannot load module...` text and `Reload` button.

package/docs/log-service.mdx

@@ -0,0 +1,57 @@
+---
+title: Log Service
+---
+
+`@servicetitan/log-service` contains client-side log service interfaces and provider component. Currently it's consumer application responsibility to provide log service implementation.
+
+## Package contents
+
+### ILogService
+
+Log service interface. It has 3 methods to log messages of different severity.
+
+```tsx
+interface ILogService {
+    error: Function;
+    warning: Function;
+    info: Function;
+}
+```
+
+### LogServiceProvider
+
+React Component that passes log service class to `@servicetitan/react-ioc` container.
+
+#### Props
+
+|  Name   |               Type                |    Description    | Required |
+| :-----: | :-------------------------------: | :---------------: | :------: |
+| `value` | `interfaces.Newable<ILogService>` | Log service class |   Yes    |
+
+### LOG_SERVICE_TOKEN
+
+InversifyJS token to resolve log service from `@servicetitan/react-ioc` container.
+
+### In the Monolith
+
+Here's an example of how to use it in the monolith:
+
+```tsx
+import { Log } from '@servicetitan/log-service';
+
+const [log] = useDependencies(Log);
+
+log.warning({
+    category: 'MarketingAnalytics',
+    code: 'NotFound',
+    message: 'Unknown path requested',
+    data: {
+        requestUrl:
+            routeProps.location.pathname + routeProps.location.search + routeProps.location.hash,
+    },
+});
+```
+
+Here's what it looks like in Kibana:
+
+![image](https://user-images.githubusercontent.com/3007167/155615447-4926f9c3-f358-482d-a84a-c72d6ed88740.png)

package/docs/react-ioc.mdx

@@ -0,0 +1,161 @@
+---
+title: React IoC
+---
+
+`@servicetitan/react-ioc` is an implementation of [InversifyJS](https://github.com/inversify/InversifyJS) for react applications, it uses Context API of React 16 to manage containers.
+
+## 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
+
+## Examples
+
+### @injectable
+
+Alias for [@injectable](https://github.com/inversify/InversifyJS#step-2-declare-dependencies-using-the-injectable--inject-decorators) from InversifyJS.
+
+```tsx
+@injectable()
+class Store {
+    value = 123;
+}
+```
+
+### Container
+
+Alias for [Container](https://github.com/inversify/InversifyJS/blob/master/wiki/container_api.md) from InversifyJS, could be used for testing purposes.
+
+```tsx
+const rootContainer = new Container();
+
+rootContainer.bind(Store).toSelf();
+
+const store = container.get(Store);
+```
+
+### @provide
+
+A decorator used to inject the required information in the current level of hierarchy.
+
+_NOTE:_ `@provide` creates new InversifyJS container with a link to a parent one meaning that all React components below `@provide` will try to resolve stores from closest container first. Using this mechanism you can re-provide the same store just for the sub-part of React component tree if needed. More info about hierarhical DI can be found [here](https://github.com/inversify/InversifyJS/blob/master/wiki/hierarchical_di.md).
+
+```tsx
+const Component: React.FC = provide({
+    singletons: [Store],
+})(() => {
+    return <SubComponent />;
+});
+```
+
+```tsx
+@provide({
+    singletons: [Store],
+})
+class Component extends React.Component {
+    render() {
+        return <SubComponent />;
+    }
+}
+```
+
+### Provider
+
+A functional component equivalent to [@provide](#provide)
+
+```tsx
+<Provider singletons={[Store]}>
+    <Component />
+</Provider>
+```
+
+### @inject
+
+Alias for [@inject](https://github.com/inversify/InversifyJS#step-2-declare-dependencies-using-the-injectable--inject-decorators) from InversifyJS, could be used for injecting information in not React classes.
+
+```tsx
+class ConsumerStore {
+    constructor(@inject(Store) private readonly store: Store) {}
+}
+```
+
+### useDependencies
+
+A Hook that can be used in order to consume IoC container in any child functional component.
+
+```tsx
+const SubComponent: React.FC = () => {
+    const [store] = useDependencies(Store);
+
+    return <div>{store.value}</div>;
+};
+```
+
+### injectDependency
+
+A Hook that can be used in order to consume IoC container in any child component.
+
+```tsx
+class SubComponent extends React.Component {
+    @injectDependency(Store)
+    store!: Store;
+
+    render() {
+        return <span>{this.store.value}</span>;
+    }
+}
+```
+
+### Using tokens
+
+#### Creating a token
+
+```tsx
+interface ILogger {
+    error(e: Error): void;
+}
+
+const LOGGER_TOKEN = symbolToken<ILogger>('LOGGER_TOKEN');
+```
+
+#### Injecting a service by token
+
+```tsx
+class ErrorBoundary extends React.Component {
+    state = { hasError: false };
+
+    @injectDependency(LOGGER_TOKEN)
+    logger!: ILogger;
+
+    componentDidCatch(e: Error) {
+        this.logger.error(e);
+        this.setState({ hasError: true });
+    }
+
+    render() {
+        if (this.state.hasError) {
+            return <div>Something went wrong...</div>;
+        }
+
+        return this.props.children;
+    }
+}
+```
+
+#### Providing a service
+
+```tsx
+class Logger implements ILogger {
+    error(e: Error) {
+        console.log(e);
+    }
+}
+
+const App = provide({ singletons: [{ provide: LOGGER_TOKEN, useClass: Logger }] })(() => (
+    <ErrorBoundary>
+        <Router />
+    </ErrorBoundary>
+));
+```

package/docs/startup.mdx

@@ -0,0 +1,340 @@
+---
+title: Startup
+---
+
+import Admonition from '@theme/Admonition';
+import { VersionHistory, Changes } from '@site/src/components/version-history';
+
+<VersionHistory>
+    <Changes forVersion="v22.11.0">
+        Added <code>install</code> command that replaces legacy bootstrap.js
+        and changed <code>init</code> template to use it.
+    </Changes>
+    <Changes forVersion="v22.9.0">
+        Changed <code>build</code> command to automatically register Kendo UI licence
+        and added <code>kendo-ui-license</code> command to manually register Kendo UI license.
+    </Changes>
+    <Changes forVersion="v22.7.0">
+        <p>MFEs now support providing custom webpack configuration too! Create <code>webpack.dev.config.js</code> and/or <code>webpack.prod.config.js</code> for development and production modes respectively.
+        Put these config files at the level of your app folder (usually, <code>packages/application</code>) instead of the root directory of your repo.</p>
+        <Admonition type="caution" title="Caution">
+            You cannot use the <code>createWebpackConfig</code> function in an MFE custom webpack config file at the time of writing. You'll get an error.
+        </Admonition>
+    </Changes>
+    <Changes forVersion="v22.3.0">
+        The <code>--stat</code> argument of the <code>build</code> command now works for MFEs too.
+    </Changes>
+    <Changes forVersion="v22.2.1">
+        <p>
+            <code>mfe-publish</code> command is added with 2 arguments to clean up (unpublish)
+            published MFE packages and 7 more arguments to publish MFEs.
+        </p>
+        <Admonition type="note" title="Note">
+            The <code>noTag</code> argument is not used at the moment of writing.
+        </Admonition>
+        <span>
+            Two more auxiliary commands (shortcuts) are also added: <code>mfe-package-clean</code>{' '}
+            and <code>mfe-package-publish</code>.
+        </span>
+    </Changes>
+    <Changes forVersion="v22.0.4">
+        <code>stat</code> argument is added for the <code>build</code> command. It enables
+        webpack-bundle-analyzer and generates a bundle report. Examples of usage:{' '}
+        <code>startup build --stat</code>
+    </Changes>
+    <Changes forVersion="v21.3.1">
+        Both <code>start</code> and <code>build</code> commands accept <code>esbuild</code> argument
+        to enable the esbuild loader. Starting this version it works both for development and
+        production. Examples of usage: <code>startup start --esbuild</code>,{' '}
+        <code>startup build --esbuild</code>
+    </Changes>
+
+</VersionHistory>
+
+[@servicetitan/startup](https://github.com/servicetitan/uikit/tree/master/packages/startup) is a command-line interface (CLI) to create multi-package Lerna projects with the support of TypeScript Project References and React. It offers a modern build setup with no configuration.
+
+## Why use this package?
+
+#### Less to learn
+
+No need to learn and configure build, lint, and testing environment. Quick reloads help to focus on development. When it's time to deploy bundles are optimized automatically.
+
+#### Dependencies encapsulation
+
+It's overwhelming how many development dependencies are required to work with the modern web application, with [@servicetitan/startup](https://github.com/servicetitan/uikit/tree/master/packages/startup) everything is already pre-included.
+
+#### Easy to maintain
+
+Updating build tooling is typically a daunting and time-consuming task. When new versions of [@servicetitan/startup](https://github.com/servicetitan/uikit/tree/master/packages/startup) are released, you just need to bump its version.
+
+## Commands
+
+### init
+
+Generates initial project structure. This command should be run via `npx` in an empty folder.
+
+```
+npx -y @servicetitan/startup@latest init
+```
+
+### install
+
+Installs the package dependencies.
+
+### start
+
+Runs package in the development mode. Applications will be hosted on sequential free ports starting from 8080. Pages will automatically reload on changes to the code.
+
+#### Arguments
+
+-   `--scope <glob>` - Include only packages with names matching the given glob.
+-   `--ignore <glob>` - Exclude packages with names matching the given glob.
+-   `--esbuild` - Use [esbuild-loader](https://github.com/privatenumber/esbuild-loader) to process TypeScript files instead of ts-loader.
+
+### build
+
+Build packages for production to the `dist/bundle` folders. It correctly bundles them in production mode and optimizes the build for the best performance. The builds are minified and the filenames include the hashes. Apps are ready to be deployed.
+
+#### Arguments
+
+-   `--scope <glob>` - Include only packages with names matching the given glob.
+-   `--ignore <glob>` - Exclude packages with names matching the given glob.
+-   `--cdn-path <url>` - Specify the base path for all the assets within the application.
+-   `--esbuild` - Use [esbuild-loader](https://github.com/privatenumber/esbuild-loader) to process TypeScript files instead of ts-loader.
+-   `--stat` - Generate bundle report with [webpack-bundle-analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer). Starting `v22.3.0` works for [MFEs](/docs/frontend/micro-frontends) too.
+
+### test
+
+Runs all existing tests in all packages.
+
+To run tests a subset of tests is possible to pass paths to specific directories or test files as positional parameters.
+
+```sh
+startup test -- packages/desktop/app/modules/inventory/
+```
+
+### lint
+
+Runs ESLint and Stylelint for all codebase projects.
+
+To run ESLint and Stylelint on certain packages or subsystems it is possible to pass paths to specific directories as positional parameters.
+
+```sh
+startup lint -- packages/desktop/app/modules/inventory/
+```
+
+You can use multiple paths and your shell expressions which expand to directories.
+
+```sh
+startup lint -- packages/desktop/app/modules/lead/ packages/desktop/app/modules/inventory/
+startup lint -- packages/desktop/app/modules/{lead,inventory}/
+```
+
+#### Arguments
+
+-   `--scope <glob>` - Include only packages with names matching the given glob.
+-   `--ignore <glob>` - Exclude packages with names matching the given glob.
+-   `--fix` - Fix linting issues.
+
+### mfe-publish
+
+This is an umbrella command for both unpublishing (cleaning up, `mfe-package-clean`) and publishing (`mfe-package-publish`) 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` argument for more details.
+
+#### Arguments
+
+##### Clean-up arguments
+
+-   `--clean` - Start the clean-up script instead of publishing.
+-   `--count <number>` - The number of packages to be unpublished (cleaned up). The default value is 5. This argument has effect only when `--clean` is specified too.
+
+#### Publish arguments
+
+-   `--build <glob>` - Optional build version, normally should not be specified. If not specified a `<branch_name>.<commit_hash>` value will be assigned. For example, `next.bdac90f5`. The full version number of the package being published will then be `0.0.0-next.bdac90f5` (a unique value per each release hence no collisions when publishing the package).
+-   `--dry` - Invoke [npm publish --dry-run](https://docs.npmjs.com/cli/v7/commands/npm-publish#dry-run) instead of actually publishing anything.
+-   `--branch <string>` - Optional branch name. The current branch name is used if no value is specified. The branch name is used in constructing the build version in case `--build` is not specified.
+-   `--force` - Attempts to force publish the package in case no branch configuration is found for the specified branch (`--branch` or current branch).
+-   `--tag <string> | false` - If the value is `false` the package will be published without a custom [tag](https://docs.npmjs.com/cli/v7/commands/npm-publish#tag) (meaning it will be published with the default `latest` tag). If another value is specified it will be used as the tag name otherwise the tag value will be mapped from [following object](https://github.com/servicetitan/uikit/blob/master/packages/startup/src/cli/commands/mfe-publish.ts#L311-L316). For example, in case of branch name `master` the package will be published with the `prod` tag, etc.
+-   `--noTag <string>` - This argument is currently not used.
+
+#### Other auxiliary mfe-publish commands
+
+In addition to `mfe-publish` also `mfe-package-clean` and `mfe-package-publish` commands are added.
+
+`mfe-package-clean` command with a `--count` argument is equivalent to `mfe-publish` with `--count` and `--clean` arguments.
+
+`mfe-package-publish` accepts all arguments mentioned above except for `--clean`, `--count`, and `--scope` i.e. this command only publishes packages.
+
+### kendo-ui-license
+
+Activates KendoReact components by installing the license key. The license key is only installed if the project depends on `@progress/kendo` components. Otherwise, this command has no effect.
+
+**Note:** The [build](#build) command automatically detects when a project uses KendoRect components and runs this command.
+
+Use it to install the license key separately from a build, or to override the default license key.
+
+```sh
+$ npx startup kendo-ui-license
+```
+
+To install a different license, set the KENDO_UI_LICENSE environment variable to the key to use.
+
+```sh
+$ export KENDO_UI_LICENSE=<license-key>
+$ npx startup kendo-ui-license
+```
+
+## Build Stages
+
+1. Generation of TypeScript definition files from CSS, LESS, and SASS Modules (by `typed-css-modules`) for each Lerna package and copying all assets and style files to the `dist` folder for each non-webpack Lerna package in parallel.
+1. Building all non-webpack Lerna packages by TypeScript CLI in hierarchical order via [TypeScript project references](https://www.typescriptlang.org/docs/handbook/project-references.html).
+1. Running Webpack bundling for each webpack Lerna package in parallel.
+
+#### Important Note
+
+It doesn't support hierarchical watch because we are not maintaining hierarchy ourselves, so we have to build everything first and then run watch when order is no longer important. Also, it doesn't support dependencies between the Webpack bundles.
+
+## CSS Modules
+
+This project supports [CSS Modules](https://github.com/css-modules/css-modules) alongside regular stylesheets using the `[name].module.{css,less,scss}` file naming convention. It allows the scoping of CSS by automatically creating a unique class name.
+
+## Configuration Customization
+
+The zero-configuration approach is a good fit for most use cases, but sometimes applications may need to extend or override configuration.
+
+### Project Root
+
+#### `package.json` Configuration
+
+Sometimes you may need to change the configuration of project-wide tools, e.g., extend the ESLint configuration. For these purposes, we support the `cli` node in the root `package.json` file with the following options:
+
+```json title="package.json"
+{
+    ...
+    "cli": {
+        "lint": {
+            "eslint": {
+                // ESLint options (https://eslint.org/docs/user-guide/configuring)
+            },
+            "stylelint": {
+                // Stylelint options (https://stylelint.io/user-guide/configure)
+            }
+        },
+        "test": {
+            // Jest options (https://jestjs.io/docs/next/configuration)
+        }
+    }
+    ...
+}
+```
+
+### Package
+
+#### `package.json` Configuration
+
+[@servicetitan/startup](https://github.com/servicetitan/uikit/tree/master/packages/startup) supports different build behaviors for packages. You may change it through the `cli` node in the package's `package.json` file. By default, it applies the regular Webpack bundling.
+
+##### Non-application packages
+
+A project can contain supporting packages such as shared components, utilities, etc. It's recommended to disable the Webpack bundle for them.
+
+```json title="package.json"
+{
+    ...
+    "cli": {
+        "webpack": false
+    }
+    ...
+}
+```
+
+##### Microfrontends
+
+You can find detailed information [here](/docs/frontend/micro-frontends).
+
+```json title="package.json"
+{
+    ...
+    "cli": {
+        "web-component": true
+    }
+    ...
+}
+```
+
+##### Application Port
+
+Sometimes you may need to have a fixed port for the started application.
+
+```json title="package.json"
+{
+    ...
+    "cli": {
+        "webpack": {
+            "port": 8888
+        }
+    }
+    ...
+}
+```
+
+#### Webpack Configuration
+
+If you need to add additional rules or change the build output path or make any other customization of the Webpack configuration, you should create `webpack.{env}.config.js` files in the package's root folder. These files should call `createWebpackConfig` with the required configuration.
+
+##### createWebpackConfig
+
+Accepts an object with two fields: `configuration` and `plugins` (currently only `ForkTsCheckerWebpackPlugin` and `HtmlWebpackPluginOptions` are [supported](https://github.com/servicetitan/uikit/blob/master/packages/startup/src/webpack/shared.config.ts#L34-L40), and `MiniCssExtractPlugin` is only supported for production builds) with settings overrides for Webpack and its plugins. Returns default Webpack configuration depends on provided `mode` with applied overrides.
+
+```js title="webpack.dev.config.js"
+const path = require('path');
+
+const { createWebpackConfig } = require('@servicetitan/startup');
+
+module.exports = createWebpackConfig({
+    configuration: {
+        mode: 'development',
+        output: { path: path.resolve(__dirname, '../../wwwroot') },
+    },
+});
+```
+
+```js title="webpack.prod.config.js"
+const path = require('path');
+
+const { createWebpackConfig } = require('@servicetitan/startup');
+
+module.exports = createWebpackConfig({
+    configuration: {
+        mode: 'production',
+        output: { path: path.resolve(__dirname, '../../wwwroot') },
+    },
+});
+```
+
+##### MFE webpack config
+
+Since `v22.7.0` providing custom webpack configuration for MFEs is also supported. However, there is a caveat. You can't use the `createWebpackConfig` to create the configuration as MFEs exist in two variants: a full build (includes all dependencies of MFE) and a light build (has shared dependencies with the host app and does not bundle these deps). See the [discussion here](https://github.com/servicetitan/uikit/pull/1721#discussion_r1183007790) for more info. Below are examples of MFE webpack configs. These objects are then internally passed to `createWebpackConfig` (so the same limitation applies meaning only a few `plugins` can be specified in the config file, see the previous section on `createWebpackConfig`).
+
+```js title="webpack.dev.config.js"
+const path = require('path');
+
+module.exports = {
+    configuration: {
+        mode: 'development',
+        output: { path: path.resolve(__dirname, '../../wwwroot') },
+    },
+    plugins: [...]
+};
+```
+
+```js title="webpack.prod.config.js"
+const path = require('path');
+
+module.exports = {
+    configuration: {
+        mode: 'production',
+        output: { path: path.resolve(__dirname, '../../wwwroot') },
+    },
+    plugins: [...]
+};
+```

package/package.json

@@ -0,0 +1,19 @@
+{
+    "name": "@servicetitan/docs-uikit",
+    "version": "22.11.0",
+    "description": "",
+    "repository": {
+        "type": "git",
+        "url": "https://github.com/servicetitan/uikit.git",
+        "directory": "packages/docs"
+    },
+    "files": [
+        "docs"
+    ],
+    "publishConfig": {
+        "access": "public"
+    },
+    "cli": {
+        "webpack": false
+    }
+}