mirror of
https://github.com/elastic/kibana.git
synced 2025-04-22 17:04:01 -04:00
afb09ccf8a
## Dearest Reviewers 👋 I've been working on this branch with @mistic and @tylersmalley and we're really confident in these changes. Additionally, this changes code in nearly every package in the repo so we don't plan to wait for reviews to get in before merging this. If you'd like to have a concern addressed, please feel free to leave a review, but assuming that nobody raises a blocker in the next 24 hours we plan to merge this EOD pacific tomorrow, 12/22. We'll be paying close attention to any issues this causes after merging and work on getting those fixed ASAP. 🚀 --- The operations team is not confident that we'll have the time to achieve what we originally set out to accomplish by moving to Bazel with the time and resources we have available. We have also bought ourselves some headroom with improvements to babel-register, optimizer caching, and typescript project structure. In order to make sure we deliver packages as quickly as possible (many teams really want them), with a usable and familiar developer experience, this PR removes Bazel for building packages in favor of using the same JIT transpilation we use for plugins. Additionally, packages now use `kbn_references` (again, just copying the dx from plugins to packages). Because of the complex relationships between packages/plugins and in order to prepare ourselves for automatic dependency detection tools we plan to use in the future, this PR also introduces a "TS Project Linter" which will validate that every tsconfig.json file meets a few requirements: 1. the chain of base config files extended by each config includes `tsconfig.base.json` and not `tsconfig.json` 1. the `include` config is used, and not `files` 2. the `exclude` config includes `target/**/*` 3. the `outDir` compiler option is specified as `target/types` 1. none of these compiler options are specified: `declaration`, `declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`, `paths` 4. all references to other packages/plugins use their pkg id, ie: ```js // valid { "kbn_references": ["@kbn/core"] } // not valid { "kbn_references": [{ "path": "../../../src/core/tsconfig.json" }] } ``` 5. only packages/plugins which are imported somewhere in the ts code are listed in `kbn_references` This linter is not only validating all of the tsconfig.json files, but it also will fix these config files to deal with just about any violation that can be produced. Just run `node scripts/ts_project_linter --fix` locally to apply these fixes, or let CI take care of automatically fixing things and pushing the changes to your PR. > **Example:** [`64e93e5` (#146212)](64e93e5806) When I merged main into my PR it included a change which removed the `@kbn/core-injected-metadata-browser` package. After resolving the conflicts I missed a few tsconfig files which included references to the now removed package. The TS Project Linter identified that these references were removed from the code and pushed a change to the PR to remove them from the tsconfig.json files. ## No bazel? Does that mean no packages?? Nope! We're still doing packages but we're pretty sure now that we won't be using Bazel to accomplish the 'distributed caching' and 'change-based tasks' portions of the packages project. This PR actually makes packages much easier to work with and will be followed up with the bundling benefits described by the original packages RFC. Then we'll work on documentation and advocacy for using packages for any and all new code. We're pretty confident that implementing distributed caching and change-based tasks will be necessary in the future, but because of recent improvements in the repo we think we can live without them for **at least** a year. ## Wait, there are still BUILD.bazel files in the repo Yes, there are still three webpack bundles which are built by Bazel: the `@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and the `@kbn/monaco` workers. These three webpack bundles are still created during bootstrap and remotely cached using bazel. The next phase of this project is to figure out how to get the package bundling features described in the RFC with the current optimizer, and we expect these bundles to go away then. Until then any package that is used in those three bundles still needs to have a BUILD.bazel file so that they can be referenced by the remaining webpack builds. Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
44 lines
No EOL
2.5 KiB
Text
44 lines
No EOL
2.5 KiB
Text
---
|
|
id: kibDevDocsOpsKbnPm
|
|
slug: /kibana-dev-docs/ops/kbn-pm
|
|
title: "@kbn/pm"
|
|
description: 'The tool which bootstraps the repo and helps work with packages'
|
|
date: 2022-07-14
|
|
tags: ['kibana', 'dev', 'contributor', 'operations', 'packages', 'scripts']
|
|
---
|
|
|
|
`@kbn/pm` is the tool that we use to bootstrap the Kibana repository, build packages with Bazel, and run scripts in packages.
|
|
|
|
## commands
|
|
|
|
### `yarn kbn bootstrap`
|
|
|
|
Use this command to install dependencies, build packages, and prepare the repo for local development.
|
|
|
|
### `yarn kbn watch`
|
|
|
|
Use this command to build all packages and make sure that they are rebuilt as you make changes.
|
|
|
|
### and more!
|
|
|
|
There are several commands supported by `@kbn/pm`, but rather than documenting them here they are documented in the help text. Please run `yarn kbn --help` locally to see the most up-to-date info.
|
|
|
|
## Why isn't this TypeScript?
|
|
|
|
Since this tool is required for bootstrapping the repository it needs to work without any dependencies installed and without a build toolchain. We accomplish this by writing the tool in vanilla JS (shocker!) and using TypeScript to validate the code which is typed via heavy use of JSDoc comments.
|
|
|
|
In order to use import/export syntax and enhance the developer experience a little we use the `.mjs` file extension.
|
|
|
|
In some cases we actually do use TypeScript files, just for defining complicated types. These files are then imported only in special TS-compatible JSDoc comments, so Node.js will never try to import them but they can be used to define types which are too complicated to define inline or in a JSDoc comment.
|
|
|
|
There are cases where `@kbn/pm` relies on code from packages, mostly to prevent reimplementing common functionality. This can only be done in one of two ways:
|
|
|
|
1. With a dynamic `await import(...)` statement that is always run after boostrap is complete, or is wrapped in a try/catch in case bootstrap didn't complete successfully.
|
|
2. By pulling in the source code of the un-built package.
|
|
|
|
Option 1 is used in several places, with contingencies in place in case bootstrap failed. Option 2 is used for two pieces of code which are needed in order to run bootstrap:
|
|
|
|
1. `@kbn/plugin-discovery` as we need to populate the `@kbn/package-map` to run Bazel
|
|
2. `@kbn/bazel-runner` as we want to have the logic for running bazel in a single location
|
|
|
|
Because we load these two packages from source, without being built, before bootstrap is ever run, they can not depend on other packages and must be written in Vanilla JS as well. |