paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 38 Packages Projects Releases Wiki Activity

remove some cli deprecation warnings

Browse Source 
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
This commit is contained in:
Fredrik Adelöw
2026-03-30 09:41:58 +02:00
parent 0336f92de8
commit 6cc48113fc
8 changed files with 30 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tooling/cli/02-build-system.md
+3 -3
View File
@@ -609,8 +609,8 @@ If set to `true`, any attempt to make a network request in frontend package test
Caching is used sparingly throughout the Backstage build system. It is always used as a way to squeeze out a little bit of extra performance, rather than requirement to keep things fast. The following is a list of places where optional caching is available:
- **TypeScript** - The default `tsconfig.json` used by Backstage projects has `incremental` set to `true`, which enables local caching of type checking results. It is however generally not recommended in CI, where `yarn tsc:full` is preferred, which sets `--incremental false`.
- **Testing** - The `backstage-cli repo test` command has a `--successCache` flag that enables caching of successful test results. This is done at the package level, meaning that if a package has not been changed since the last test run and it was successful, the testing will be skipped. This is recommended to be used in CI, but not during local development.
- **Linting** - The `backstage-cli repo lint` command has a `--successCache` flag that enables caching of successful linting results. This is done at the package level, meaning that if a package has not been changed since the last lint run and it was successful, the linting will be skipped. This is recommended to be used in CI, but not during local development.
- **Testing** - The `backstage-cli repo test` command has a `--success-cache` flag that enables caching of successful test results. This is done at the package level, meaning that if a package has not been changed since the last test run and it was successful, the testing will be skipped. This is recommended to be used in CI, but not during local development.
- **Linting** - The `backstage-cli repo lint` command has a `--success-cache` flag that enables caching of successful linting results. This is done at the package level, meaning that if a package has not been changed since the last lint run and it was successful, the linting will be skipped. This is recommended to be used in CI, but not during local development.
- **Webpack** - It is possible to enable experimental caching of frontend package builds using the `BACKSTAGE_CLI_EXPERIMENTAL_BUILD_CACHE` environment variable. This will enable the Webpack filesystem cache.
### Debugging Jest Tests
@@ -654,7 +654,7 @@ With that in mind, here are some IDEs configurations to run backstage components
}
```
3. Add a launch configuration for VS Code in `launch.json` in the `.vscode` folder.
3. Add a launch configuration for VS Code in `launch.json` in the `.vscode` folder.
A complete configuration for debugging may look like this:
```jsonc
docs/tooling/cli/03-commands.md
+12 -12
View File
@@ -120,11 +120,11 @@ Usage: backstage-cli repo lint [options]
Lint all packages in the project
Options:
--format <format> Lint report output format (default: "eslint-formatter-friendly")
--since <ref> Only lint packages that changed since the specified ref
--successCache Enable success caching, which skips running tests for unchanged packages that were successful in the previous run
--successCacheDir <path> Set the success cache location, (default: node_modules/.cache/backstage-cli)
--fix Attempt to automatically fix violations
--format <format> Lint report output format (default: "eslint-formatter-friendly")
--since <ref> Only lint packages that changed since the specified ref
--success-cache Enable success caching, which skips running tests for unchanged packages that were successful in the previous run
--success-cache-dir <path> Set the success cache location, (default: node_modules/.cache/backstage-cli)
--fix Attempt to automatically fix violations
```
## repo test
@@ -153,7 +153,7 @@ If arguments are provided, they will be forwarded to Jest and used to filter tes
yarn test packages/app/src/App.test.tsx
```
If you want to avoid re-running tests that have not changed since the last successful run in CI, you can use the `--successCache` flag. By default this cache is stored in `node_modules/.cache/backstage-cli`, but you can choose a different directory with the `--successCacheDir <path>`.
If you want to avoid re-running tests that have not changed since the last successful run in CI, you can use the `--success-cache` flag. By default this cache is stored in `node_modules/.cache/backstage-cli`, but you can choose a different directory with the `--success-cache-dir <path>`.
```text
Usage: backstage-cli repo test [options]
@@ -161,11 +161,11 @@ Usage: backstage-cli repo test [options]
Run tests, forwarding args to Jest, defaulting to watch mode
Options:
--since <ref> Only test packages that changed since the specified ref
--successCache Enable success caching, which skips running tests for unchanged packages that were successful in the previous run
--successCacheDir <path> Set the success cache location, (default: node_modules/.cache/backstage-cli)
--jest-help Show help for Jest CLI options, which are passed through
-h, --help display help for command
--since <ref> Only test packages that changed since the specified ref
--success-cache Enable success caching, which skips running tests for unchanged packages that were successful in the previous run
--success-cache-dir <path> Set the success cache location, (default: node_modules/.cache/backstage-cli)
--jest-help Show help for Jest CLI options, which are passed through
-h, --help display help for command
```
## package start
@@ -178,7 +178,7 @@ Usage: backstage-cli package start [options]
Start a package for local development
Options:
--config <path> Config files to load instead of app-config.yaml (default: [])
--config <path> Config files to load instead of app-config.yaml (default: [])
--role <name> Run the command with an explicit package role
--check Enable type checking and linting if available
--inspect Enable debugger in Node.js environments