prefer subpath over sub-path

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
This commit is contained in:
Patrik Oldsberg
2023-01-18 00:43:27 +01:00
parent e47f499403
commit 3e63951e49
2 changed files with 5 additions and 5 deletions
+4 -4
View File
@@ -650,9 +650,9 @@ The following is an excerpt of a typical setup of an isomorphic library package:
"files": ["dist"],
```
## Sub-path Exports
## Subpath Exports
The Backstage CLI supports implementation of sub-path exports through the `"exports"` field in `package.json`. It might for example look like this:
The Backstage CLI supports implementation of subpath exports through the `"exports"` field in `package.json`. It might for example look like this:
```json
"name": "@backstage/plugin-foo",
@@ -668,7 +668,7 @@ As with the rest of the Backstage CLI build system, the setup is optimized for l
TypeScript support is currently handled though the `typesVersions` field, as there is not yet a module resolution mode that works well with `"exports"`. You can craft the `typesVersions` yourself, but it will also be automatically generated by the `migrate package-exports` command.
To add sub-path exports to an existing package, simply add the desired `"exports"` fields and then run the following command:
To add subpath exports to an existing package, simply add the desired `"exports"` fields and then run the following command:
```bash
yarn backstage-cli package migrate package-exports
@@ -676,7 +676,7 @@ yarn backstage-cli package migrate package-exports
## Experimental Type Build
> Note: Experimental type builds are deprecated and will be removed in the future. They have been replaced by [sub-path exports](#sub-path-exports).
> Note: Experimental type builds are deprecated and will be removed in the future. They have been replaced by [subpath exports](#subpath-exports).
The Backstage CLI has an experimental feature where multiple different type definition files can be generated for different release stages. The release stages are marked in the [TSDoc](https://tsdoc.org/) for each individual export, using either `@public`, `@alpha`, or `@beta`. Rather than just building a single `index.d.ts` file, the build process will instead output `index.d.ts`, `index.beta.d.ts`, and `index.alpha.d.ts`. Each of these files will have exports from more unstable release stages stripped, meaning that `index.d.ts` will omit all exports marked with `@alpha` or `@beta`, while `index.beta.d.ts` will omit all exports marked with `@alpha`.