@servicetitan/docs-uikit 28.5.0 → 30.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/BREAKING_CHANGES.mdx +21 -0
- package/docs/ajax-handlers.mdx +1 -1
- package/docs/eslint-config.mdx +10 -8
- package/docs/folder-schema.mdx +16 -3
- package/docs/startup.mdx +83 -66
- package/docs/web-components.mdx +28 -14
- package/package.json +2 -2
- package/docs/component-usage.mdx +0 -66
|
@@ -2,6 +2,27 @@
|
|
|
2
2
|
title: BREAKING CHANGES
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
+
## v30.0.0
|
|
6
|
+
|
|
7
|
+
### [@servicetitan/startup](./startup)
|
|
8
|
+
|
|
9
|
+
- Upgraded ESLint to v9.x and dropped support for legacy "eslintrc" configuration. See [Upgrading to ESLint v9.x](/docs/frontend/upgrading-to-eslint-v9) for guidance.
|
|
10
|
+
|
|
11
|
+
### [@servicetitan/eslint-config](./eslint-config)
|
|
12
|
+
|
|
13
|
+
- Dropped support for legacy "eslintrc" configuration
|
|
14
|
+
|
|
15
|
+
## v29.0.0
|
|
16
|
+
|
|
17
|
+
### [@servicetitan/startup](./startup)
|
|
18
|
+
|
|
19
|
+
- Dropped support for Node 18.
|
|
20
|
+
Update Github workflows and Docker containers to use Node v20 or later, and bump the `engines.node` property in package.json files to >=20 or >=22.
|
|
21
|
+
|
|
22
|
+
- Added safeguards to mfe-publish to avoid accidentally deleting production bundles
|
|
23
|
+
- Changed `--clean` to never remove old versions that have a tag
|
|
24
|
+
- Changed the default behavior of `--clean` to only remove old versions from the current branch. Use `--branch` to remove old versions from a different branch and use `--all` to remove old versions from all branches.
|
|
25
|
+
|
|
5
26
|
## v28.0.0
|
|
6
27
|
|
|
7
28
|
### [@servicetitan/startup](./startup)
|
package/docs/ajax-handlers.mdx
CHANGED
|
@@ -86,7 +86,7 @@ See [Authentication Adapters](#authentication-adapters) for more information.
|
|
|
86
86
|
|
|
87
87
|
The authentication endpoint for protected resources.
|
|
88
88
|
|
|
89
|
-
- For **Bearer** authentication, this is the endpoint that returns the bearer token to send in **Authorization** headers. Defaults to `${baseURL}/
|
|
89
|
+
- For **Bearer** authentication, this is the endpoint that returns the bearer token to send in **Authorization** headers. Defaults to `${baseURL}/auth`.
|
|
90
90
|
|
|
91
91
|
- For **Token server** authentication, this is the "silent login" endpoint. Defaults to `${baseURL}/bff/silent-login`.
|
|
92
92
|
|
package/docs/eslint-config.mdx
CHANGED
|
@@ -20,18 +20,20 @@ title: ESLint & Stylelint configurations
|
|
|
20
20
|
|
|
21
21
|
#### In the Lerna project
|
|
22
22
|
|
|
23
|
-
```
|
|
24
|
-
{
|
|
25
|
-
|
|
26
|
-
|
|
23
|
+
```js title="eslint.config.js"
|
|
24
|
+
import { defineConfig } from 'eslint/config';
|
|
25
|
+
import mono from '@servicetitan/eslint-config/mono';
|
|
26
|
+
|
|
27
|
+
export default defineConfig(mono);
|
|
27
28
|
```
|
|
28
29
|
|
|
29
30
|
#### Without Lerna
|
|
30
31
|
|
|
31
|
-
```
|
|
32
|
-
{
|
|
33
|
-
|
|
34
|
-
|
|
32
|
+
```js title="eslint.config.js"
|
|
33
|
+
import { defineConfig } from 'eslint/config';
|
|
34
|
+
import single from '@servicetitan/eslint-config/single';
|
|
35
|
+
|
|
36
|
+
export default defineConfig(single);
|
|
35
37
|
```
|
|
36
38
|
|
|
37
39
|
### Stylelint
|
package/docs/folder-schema.mdx
CHANGED
|
@@ -18,9 +18,22 @@ Folder schema is a flexible tool to configure a strict hierarchy of files in you
|
|
|
18
18
|
|
|
19
19
|
Contains `@servicetitan/folder-schema/check` rule with the next options:
|
|
20
20
|
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
21
|
+
| Name | Description |
|
|
22
|
+
| :--------- | :------------------------------------------------------------------------------------------------------------------------------ |
|
|
23
|
+
| `config` | Object with a configuration of files hierarchy |
|
|
24
|
+
| `root?` | Optional entry point to start recursive checking. Defaults to the current working directory. |
|
|
25
|
+
| `docLink?` | Optional link to a document describing a required files hierarchy. Defaults to https://docs.st.dev/docs/frontend/file-structure |
|
|
26
|
+
|
|
27
|
+
### Configuration
|
|
28
|
+
|
|
29
|
+
Use the `eslint.config.{js,cjs,mjs}` file to configure rules using the [flag config](https://eslint.org/docs/latest/use/configure/configuration-files) style.
|
|
30
|
+
|
|
31
|
+
```js title="eslint.config.js"
|
|
32
|
+
import folderSchemaPlugin from '@servicetitan/eslint-plugin-folder-schema';
|
|
33
|
+
|
|
34
|
+
// Call configs.recommended with desired options
|
|
35
|
+
export = [...folderSchemaPlugin.configs.recommended({ config: require.resolve('./config') })];
|
|
36
|
+
```
|
|
24
37
|
|
|
25
38
|
## @servicetitan/folder-lint
|
|
26
39
|
|
package/docs/startup.mdx
CHANGED
|
@@ -26,54 +26,68 @@ Updating build tooling is typically a daunting and time-consuming task. When new
|
|
|
26
26
|
Experimental flags don't follow semver. There might be breaking changes in minor versions of `@servicetitan/startup` when you opt-in to experimental flags.
|
|
27
27
|
:::
|
|
28
28
|
|
|
29
|
-
###
|
|
29
|
+
### convert-eslint-config
|
|
30
30
|
|
|
31
|
-
|
|
31
|
+
Convert an ESLint v8 configuration to v9 format.
|
|
32
32
|
|
|
33
33
|
```sh
|
|
34
|
-
$ npx
|
|
34
|
+
$ npx startup convert-eslint-config
|
|
35
35
|
```
|
|
36
36
|
|
|
37
|
-
|
|
37
|
+
Use this command when upgrading from ESLint v8 to v9, to convert a v8 `.eslintrc.json` to the equivalent `eslint.config.mjs`. See [Upgrading to ESLint v9.x](/docs/frontend/upgrading-to-eslint-v9) for guidance on upgrading to ESLint v9.
|
|
38
38
|
|
|
39
|
-
|
|
39
|
+
The command takes no arguments. Simply run it from a directory with `.eslintrc.json` and it creates `eslint.config.mjs` in the same location.
|
|
40
40
|
|
|
41
|
-
|
|
41
|
+
:::caution
|
|
42
|
+
Comments are not copied from the source `.eslintrc.json` to the output file.
|
|
43
|
+
If the source file contains important comments, copy them manually to the output file.
|
|
44
|
+
:::
|
|
42
45
|
|
|
43
|
-
###
|
|
46
|
+
### build
|
|
44
47
|
|
|
45
|
-
|
|
48
|
+
Build packages for production to the `dist/bundle` folders. It 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.
|
|
46
49
|
|
|
47
50
|
#### Arguments
|
|
48
51
|
|
|
49
|
-
-
|
|
50
|
-
-
|
|
51
|
-
-
|
|
52
|
-
-
|
|
53
|
-
-
|
|
52
|
+
- `--scope <glob>` - Include only packages with names matching the given glob.
|
|
53
|
+
- `--ignore <glob>` - Exclude packages with names matching the given glob.
|
|
54
|
+
- `--cdn-path <url>` - Specify the base path for all the assets within the application.
|
|
55
|
+
- `--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.
|
|
56
|
+
- `--esbuild` - Use [esbuild-loader](https://github.com/privatenumber/esbuild-loader) to process TypeScript files instead of ts-loader.
|
|
57
|
+
- `--experimental-bundlers` - Use experimental build optimizations (alternative loaders and bundlers)
|
|
58
|
+
- `--code-coverage` - Add [instrumentation](https://github.com/JS-DevTools/coverage-istanbul-loader) to bundled code in order to collect code coverage
|
|
54
59
|
|
|
55
|
-
###
|
|
60
|
+
### init
|
|
56
61
|
|
|
57
|
-
|
|
62
|
+
Generates initial project structure. This command should be run via `npx` in an empty folder.
|
|
58
63
|
|
|
59
|
-
|
|
64
|
+
```sh
|
|
65
|
+
$ npx -y @servicetitan/startup@latest init
|
|
66
|
+
```
|
|
60
67
|
|
|
61
|
-
|
|
62
|
-
- `--ignore <glob>` - Exclude packages with names matching the given glob.
|
|
63
|
-
- `--cdn-path <url>` - Specify the base path for all the assets within the application.
|
|
64
|
-
- `--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.
|
|
65
|
-
- `--esbuild` - Use [esbuild-loader](https://github.com/privatenumber/esbuild-loader) to process TypeScript files instead of ts-loader.
|
|
66
|
-
- `--experimental-bundlers` - Use experimental build optimizations (alternative loaders and bundlers)
|
|
67
|
-
- `--code-coverage` - Add [instrumentation](https://github.com/JS-DevTools/coverage-istanbul-loader) to bundled code in order to collect code coverage
|
|
68
|
+
### install
|
|
68
69
|
|
|
69
|
-
|
|
70
|
+
Installs the package dependencies. This command should be run via `npx` before the build.
|
|
70
71
|
|
|
71
|
-
|
|
72
|
+
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).
|
|
72
73
|
|
|
73
|
-
|
|
74
|
+
### kendo-ui-license
|
|
75
|
+
|
|
76
|
+
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.
|
|
77
|
+
|
|
78
|
+
**Note:** The [build](#build) command automatically detects when a project uses KendoRect components and runs this command.
|
|
79
|
+
|
|
80
|
+
Use it to install the license key separately from a build, or to override the default license key.
|
|
74
81
|
|
|
75
82
|
```sh
|
|
76
|
-
$ npx startup
|
|
83
|
+
$ npx startup kendo-ui-license
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
To install a different license, set the KENDO_UI_LICENSE environment variable to the key to use.
|
|
87
|
+
|
|
88
|
+
```sh
|
|
89
|
+
$ export KENDO_UI_LICENSE=<license-key>
|
|
90
|
+
$ npx startup kendo-ui-license
|
|
77
91
|
```
|
|
78
92
|
|
|
79
93
|
### lint
|
|
@@ -93,36 +107,41 @@ $ npx startup lint -- packages/desktop/app/modules/lead/ packages/desktop/app/mo
|
|
|
93
107
|
$ npx startup lint -- packages/desktop/app/modules/{lead,inventory}/
|
|
94
108
|
```
|
|
95
109
|
|
|
96
|
-
####
|
|
110
|
+
#### Options
|
|
97
111
|
|
|
98
|
-
-
|
|
99
|
-
-
|
|
100
|
-
-
|
|
112
|
+
- `--scope <glob>` - Include only packages with names matching the given glob.
|
|
113
|
+
- `--ignore <glob>` - Exclude packages with names matching the given glob.
|
|
114
|
+
- `--fix` - Fix linting issues.
|
|
101
115
|
|
|
102
116
|
### mfe-publish
|
|
103
117
|
|
|
104
|
-
This is an umbrella command for both unpublishing (cleaning up
|
|
118
|
+
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.
|
|
105
119
|
|
|
106
|
-
####
|
|
120
|
+
#### Publishing options
|
|
107
121
|
|
|
108
|
-
|
|
122
|
+
| Option | Description |
|
|
123
|
+
| :------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
124
|
+
| `--build <glob>` | Optional build version that normally should not be specified. Defaults to `<branch_name>.<commit_hash>`. For example, if git commit `bdac90f5` is published from branch `next`, the build version is`next.bdac90f5`, and the full version is `0.0.0-next.bdac90f5`. This ensures each release has a unique version with no collisions. |
|
|
125
|
+
| `--dry` | Invoke [npm publish --dry-run](https://docs.npmjs.com/cli/v7/commands/npm-publish#dry-run) instead of actually publishing anything. |
|
|
126
|
+
| `--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. |
|
|
127
|
+
| `--force` | Forces publishing the package when no configuration was found for the specified branch (`--branch` or current branch). |
|
|
128
|
+
| `--tag <string>` | The [tag](https://docs.npmjs.com/cli/v7/commands/npm-publish#tag) to assign to the published version. Defaults to the tag associated with the branch from the custom [branch config](#branch-configs) or, if there is no custom branch config, from the [default branch config](https://github.com/servicetitan/uikit/blob/master/packages/startup/src/utils/get-branch-configs.ts#L3). For example, by default a package published from the `master` branch is tagged `prod`. Becasue NPM v11 requires pre-release versions to have a tag, if there is no custom or default tag for the branch, the package is tagged "latest". |
|
|
109
129
|
|
|
110
|
-
|
|
111
|
-
- `--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.
|
|
112
|
-
- `--branch` - Clean versions related to the current git branch. This argument has effect only when `--clean` is specified too.
|
|
113
|
-
- `--branch <branch_name>` - Clean versions related to the specified git branch. This argument has effect only when `--clean` is specified too.
|
|
130
|
+
#### Unpublishing options
|
|
114
131
|
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
132
|
+
| Option | Descripiton |
|
|
133
|
+
| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
134
|
+
| `--clean` | Instructs `mfe-publish` to remove old versions instead of publishing. |
|
|
135
|
+
| `--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. |
|
|
136
|
+
| `--branch <name>` | Remove old versions associated with the specified branch. Defaults to the current branch (i.e., `git branch --show-current`) |
|
|
137
|
+
| `--all` | Remove old versions associated with all [recognized branches](#branch-configs). This overrides `--branch`. |
|
|
138
|
+
| `--dry` | Log what the command would do without actually unpublishing anything. |
|
|
122
139
|
|
|
123
140
|
#### Branch configs
|
|
124
141
|
|
|
125
|
-
|
|
142
|
+
By default `mfe-publish` only publishes from a few [recognized branches](https://github.com/servicetitan/uikit/blob/master/packages/startup/src/utils/get-branch-configs.ts#L3) and you must use `--force` to publish from others.
|
|
143
|
+
|
|
144
|
+
To customize the recognized branches for an MFE set `cli.web-component.branches` in the MFE's package.json to an object that maps branch names to the associated tag. For example,
|
|
126
145
|
|
|
127
146
|
```json
|
|
128
147
|
"cli": {
|
|
@@ -136,33 +155,28 @@ To customize the publish tags for your MFE set `cli.web-component.branches` to a
|
|
|
136
155
|
}
|
|
137
156
|
```
|
|
138
157
|
|
|
139
|
-
-
|
|
140
|
-
|
|
141
|
-
#### Other auxiliary mfe-publish commands
|
|
142
|
-
|
|
143
|
-
In addition to `mfe-publish` also `mfe-package-clean` and `mfe-package-publish` commands are added.
|
|
158
|
+
- `publishTag: string` - Tag used when publishing package.
|
|
144
159
|
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
`mfe-package-publish` accepts all arguments mentioned above except for `--clean`, `--count`, and `--scope` i.e. this command only publishes packages.
|
|
160
|
+
### start
|
|
148
161
|
|
|
149
|
-
|
|
162
|
+
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.
|
|
150
163
|
|
|
151
|
-
|
|
164
|
+
#### Arguments
|
|
152
165
|
|
|
153
|
-
|
|
166
|
+
- `--scope <glob>` - Include only packages with names matching the given glob.
|
|
167
|
+
- `--ignore <glob>` - Exclude packages with names matching the given glob.
|
|
168
|
+
- `--esbuild` - Use [esbuild-loader](https://github.com/privatenumber/esbuild-loader) to process TypeScript files instead of ts-loader.
|
|
169
|
+
- `--experimental-bundlers` - Use experimental build optimizations (alternative loaders and bundlers)
|
|
170
|
+
- `--code-coverage` - Add [instrumentation](https://github.com/JS-DevTools/coverage-istanbul-loader) to bundled code in order to collect code coverage
|
|
154
171
|
|
|
155
|
-
|
|
172
|
+
### test
|
|
156
173
|
|
|
157
|
-
|
|
158
|
-
$ npx startup kendo-ui-license
|
|
159
|
-
```
|
|
174
|
+
Runs all existing tests in all packages.
|
|
160
175
|
|
|
161
|
-
To
|
|
176
|
+
To run tests a subset of tests is possible to pass paths to specific directories or test files as positional parameters.
|
|
162
177
|
|
|
163
178
|
```sh
|
|
164
|
-
$
|
|
165
|
-
$ npx startup kendo-ui-license
|
|
179
|
+
$ npx startup test -- packages/desktop/app/modules/inventory/
|
|
166
180
|
```
|
|
167
181
|
|
|
168
182
|
## Build Steps
|
|
@@ -346,6 +360,7 @@ Set `web-component` to `true` to create the support files and `light` and `full`
|
|
|
346
360
|
```
|
|
347
361
|
|
|
348
362
|
Or you can set an object with detailed configs:
|
|
363
|
+
|
|
349
364
|
```json title="package.json"
|
|
350
365
|
{
|
|
351
366
|
"cli": {
|
|
@@ -359,6 +374,7 @@ Or you can set an object with detailed configs:
|
|
|
359
374
|
```
|
|
360
375
|
|
|
361
376
|
Or you can use relative path to a file that exports an object with detailed configs (useful to share configs between multiple MFEs in repo):
|
|
377
|
+
|
|
362
378
|
```json title="package.json"
|
|
363
379
|
{
|
|
364
380
|
"cli": {
|
|
@@ -366,10 +382,11 @@ Or you can use relative path to a file that exports an object with detailed conf
|
|
|
366
382
|
}
|
|
367
383
|
}
|
|
368
384
|
```
|
|
385
|
+
|
|
369
386
|
###### Web component config options
|
|
370
387
|
|
|
371
|
-
-
|
|
372
|
-
-
|
|
388
|
+
- `branches` - Set git branch specific configs, used for publishing. See [Branch configs](#branch-configs).
|
|
389
|
+
- `legacyRoot` - Set to opt-out of automatic batching. See [Opting-out of automatic batching](/docs/frontend/react-18#opting-out-of-automatic-batching).
|
|
373
390
|
|
|
374
391
|
See [MFE configuration](/docs/frontend/micro-frontends/#mfe-configuration) for detailed instructions on configuring MFE applications.
|
|
375
392
|
|
package/docs/web-components.mdx
CHANGED
|
@@ -155,7 +155,7 @@ The following metadata about an MFE is available from `useMFEMetadataContext` ho
|
|
|
155
155
|
|
|
156
156
|
### getValueForEnvironment
|
|
157
157
|
|
|
158
|
-
`getValueForEnvironment` detects the
|
|
158
|
+
`getValueForEnvironment` detects the host environment and returns a corresponding value.
|
|
159
159
|
|
|
160
160
|
:::caution
|
|
161
161
|
When no value is provided for the detected environment, `getValueForEnvironment` returns `undefined`.
|
|
@@ -163,22 +163,36 @@ When no value is provided for the detected environment, `getValueForEnvironment`
|
|
|
163
163
|
|
|
164
164
|
#### Props
|
|
165
165
|
|
|
166
|
-
| Name | Type
|
|
167
|
-
| :------------------- |
|
|
168
|
-
| `values` | `Record<
|
|
169
|
-
| `defaultEnvironment` | `
|
|
170
|
-
| `hostname` | `string`
|
|
166
|
+
| Name | Type | Description |
|
|
167
|
+
| :------------------- | :----------------------- | :------------------------------------------------------------------------------------------------------------------------ |
|
|
168
|
+
| `values` | `Record<string, string>` | Object that maps each environment to a value (see below). |
|
|
169
|
+
| `defaultEnvironment` | `keyof typeof values` | The environment to use when the current environment is not recognized or is not included in `values`. Defaults to `"qa"`. |
|
|
170
|
+
| `hostname` | `string` | The hostname of the current environment. Defaults to `window.location.hostname` |
|
|
171
171
|
|
|
172
172
|
The recognized environments are:
|
|
173
173
|
|
|
174
|
-
| Environment
|
|
175
|
-
|
|
|
176
|
-
| **dev**
|
|
177
|
-
| **go**
|
|
178
|
-
| **qa**
|
|
179
|
-
| **next**
|
|
180
|
-
| **stage**
|
|
181
|
-
| **test**
|
|
174
|
+
| Environment | Description |
|
|
175
|
+
| :---------------- | :----------------------------------------------------------------- |
|
|
176
|
+
| **dev** | Development environment (i.e., `localhost`, `127.0.0.1`) |
|
|
177
|
+
| **go** | Production environment |
|
|
178
|
+
| **qa** | QA environment |
|
|
179
|
+
| **next** | Next environment |
|
|
180
|
+
| **stage** | Staging environment |
|
|
181
|
+
| **test** | Unit test environment (i.e., `process.env.NODE_ENV === 'test'`) |
|
|
182
|
+
| `<string>` | Custom environment that matches against`<string>.servicetitan.com` |
|
|
183
|
+
| `<string>.st.dev` | Custom environment that matches against `<string>.st.dev` |
|
|
184
|
+
|
|
185
|
+
#### Custom environments
|
|
186
|
+
|
|
187
|
+
Custom environments are for applications and services that run separately from the Monolith.
|
|
188
|
+
For example, to associate **prod** with `my-service.servicetitan.com` and **stage** with `my-service-stage.st.dev`:
|
|
189
|
+
|
|
190
|
+
```json
|
|
191
|
+
{
|
|
192
|
+
"my-service": "prod", // Matches my-service.servicetitan.com
|
|
193
|
+
"stage.st.dev": "stage" // Matches *stage.st.dev
|
|
194
|
+
}
|
|
195
|
+
```
|
|
182
196
|
|
|
183
197
|
#### Examples
|
|
184
198
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@servicetitan/docs-uikit",
|
|
3
|
-
"version": "
|
|
3
|
+
"version": "30.0.0",
|
|
4
4
|
"description": "",
|
|
5
5
|
"repository": {
|
|
6
6
|
"type": "git",
|
|
@@ -16,5 +16,5 @@
|
|
|
16
16
|
"cli": {
|
|
17
17
|
"webpack": false
|
|
18
18
|
},
|
|
19
|
-
"gitHead": "
|
|
19
|
+
"gitHead": "e182cbb85cf66d62f235a9ca172fc04dc705fd0a"
|
|
20
20
|
}
|
package/docs/component-usage.mdx
DELETED
|
@@ -1,66 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
title: Component Usage
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
#### [CHANGELOG (@servicetitan/component-usage)](https://github.com/servicetitan/uikit/blob/master/packages/component-usage/CHANGELOG.md)
|
|
6
|
-
|
|
7
|
-
`@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)
|
|
8
|
-
|
|
9
|
-
## Usage
|
|
10
|
-
|
|
11
|
-
### Basic Usage
|
|
12
|
-
|
|
13
|
-
```
|
|
14
|
-
$ npm install --save-dev @servicetitan/component-usage
|
|
15
|
-
$ npx component-usage
|
|
16
|
-
```
|
|
17
|
-
|
|
18
|
-
Or for one-time use with no installation:
|
|
19
|
-
|
|
20
|
-
```
|
|
21
|
-
$ npx @servicetitan/component-usage
|
|
22
|
-
```
|
|
23
|
-
|
|
24
|
-
### Options
|
|
25
|
-
|
|
26
|
-
You must specify at least one "mode" option: `--sendToDataDog`, `--outputDir`, `--teamCityOutput`.
|
|
27
|
-
|
|
28
|
-
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`.
|
|
29
|
-
|
|
30
|
-
Display help:
|
|
31
|
-
|
|
32
|
-
```
|
|
33
|
-
$ npx @servicetitan/component-usage --help
|
|
34
|
-
```
|
|
35
|
-
|
|
36
|
-
Generate stats files locally in the current directory:
|
|
37
|
-
|
|
38
|
-
```
|
|
39
|
-
$ npx @servicetitan/component-usage --outputDir .
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
Send metrics to DataDog:
|
|
43
|
-
|
|
44
|
-
```
|
|
45
|
-
$ npx @servicetitan/component-usage --sendToDataDog --dataDogApiKey ...API_KEY_GOES_HERE... --dataDogApplicationKey ...APP_KEY_GOES_HERE...
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
Porque no los dos?
|
|
49
|
-
|
|
50
|
-
```
|
|
51
|
-
$ npx @servicetitan/component-usage --outputDir . --sendToDataDog --dataDogApiKey ...API_KEY_GOES_HERE... --dataDogApplicationKey ...APP_KEY_GOES_HERE...
|
|
52
|
-
```
|
|
53
|
-
|
|
54
|
-
TeamCity output
|
|
55
|
-
|
|
56
|
-
```
|
|
57
|
-
$ npx @servicetitan/component-usage --teamCityOutput
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
## Live Data
|
|
61
|
-
|
|
62
|
-
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:
|
|
63
|
-
|
|
64
|
-
- `--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.
|
|
65
|
-
- `--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)
|
|
66
|
-
- `--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.
|