Fix typos in docs & dev_docs (#113746)

dev_docs/api_welcome.mdx

@@ -58,7 +58,7 @@ type Bar = { id: string };
 export type Foo = Bar | string;
 ```
 
-`Bar`, in the signature of `Foo`, will not be clickable because it would result in a broken link. `Bar` is not publically exported!
+`Bar`, in the signature of `Foo`, will not be clickable because it would result in a broken link. `Bar` is not publicly exported!
 
 If that isn't the case, please file an issue, it could be a bug with the system.
 

dev_docs/contributing/best_practices.mdx

@@ -196,7 +196,7 @@ Over-refactoring can be a problem in it's own right, but it's still important to
 Try not to put your PR in review mode, or merge large changes, right before Feature Freeze. It's inevitably one of the most volatile times for the
 Kibana code base, try not to contribute to this volatility. Doing this can:
 
-- increase the likelyhood of conflicts from other features being merged at the last minute
+- increase the likelihood of conflicts from other features being merged at the last minute
 - means your feature has less QA time
 - means your feature gets less careful review as reviewers are often swamped at this time
 

dev_docs/getting_started/setting_up_a_development_env.mdx

@@ -44,7 +44,7 @@ Then, install the latest version of yarn using:
 npm install -g yarn
 ```
 
-Finally, boostrap Kibana and install all of the remaining dependencies:
+Finally, bootstrap Kibana and install all of the remaining dependencies:
 
 ```sh
 yarn kbn bootstrap

dev_docs/key_concepts/saved_objects.mdx

@@ -33,7 +33,7 @@ all the "children" will be automatically included. However, when a "child" is ex
 
 ## Migrations and Backward compatibility
 
-As your plugin evolves, you may need to change your Saved Object type in a breaking way (for example, changing the type of an attribtue, or removing
+As your plugin evolves, you may need to change your Saved Object type in a breaking way (for example, changing the type of an attribute, or removing
 an attribute). If that happens, you should write a migration to upgrade the Saved Objects that existed prior to the change.
 
 <DocLink id="kibDevTutorialSavedObject" section="migrations" text="How to write a migration" />.

dev_docs/tutorials/data/search.mdx

@@ -477,7 +477,7 @@ If you don't call `clear`, you will see a warning in the console while developin
 
 The last step of the integration is restoring an existing search session. The `searchSessionId` parameter and the rest of the restore state are passed into the application via the URL. Non-URL support is planned for future releases.
 
-If you detect the presense of a `searchSessionId` parameter in the URL, call the `restore` method **instead** of calling `start`. The previous example would now become:
+If you detect the presence of a `searchSessionId` parameter in the URL, call the `restore` method **instead** of calling `start`. The previous example would now become:
 
 ```ts
 function onSearchSessionConfigChange(searchSessionIdFromUrl?: string) {

docs/api/spaces-management/copy_saved_objects.asciidoc

@@ -58,7 +58,7 @@ You can request to overwrite any objects that already exist in the target space
 NOTE: This cannot be used with the `overwrite` option.
 
 `overwrite`::
-  (Optional, boolean) When set to `true`, all conflicts are automatically overidden. When a saved object with a matching `type` and `id`
+  (Optional, boolean) When set to `true`, all conflicts are automatically overridden. When a saved object with a matching `type` and `id`
   exists in the target space, that version is replaced with the version from the source space. The default value is `false`.
 +
 NOTE: This cannot be used with the `createNewCopies` option.

docs/developer/advanced/upgrading-nodejs.asciidoc

@@ -5,7 +5,7 @@
 When running {kib} from source, you must have this version installed locally.
 
 The required version of Node.js is listed in several different files throughout the {kib} source code.
-Theses files must be updated when upgrading Node.js:
+These files must be updated when upgrading Node.js:
 
   - {kib-repo}blob/{branch}/.ci/Dockerfile[`.ci/Dockerfile`] - The version is specified in the `NODE_VERSION` constant.
     This is used to pull the relevant image from https://hub.docker.com/_/node[Docker Hub].
@@ -29,7 +29,7 @@ The following rules are not set in stone.
 Use best judgement when backporting.
 
 Currently version 7.11 and newer run Node.js 14, while 7.10 and older run Node.js 10.
-Hence, upgrades to either Node.js 14 or Node.js 10 shold be done as separate PRs.
+Hence, upgrades to either Node.js 14 or Node.js 10 should be done as separate PRs.
 
 ==== Node.js patch upgrades
 

docs/developer/architecture/security/rbac.asciidoc

@@ -104,6 +104,6 @@ Authorization: Basic foo_read_only_user password
 }
 ----------------------------------
 
-{es} checks if the user is granted a specific action. If the user is assigned a role that grants a privilege, {es} uses the <<development-rbac-privileges, {kib} privileges>> definition to associate this with the actions, which makes authorizing users more intuitive and flexible programatically.
+{es} checks if the user is granted a specific action. If the user is assigned a role that grants a privilege, {es} uses the <<development-rbac-privileges, {kib} privileges>> definition to associate this with the actions, which makes authorizing users more intuitive and flexible programmatically.
 
 Once we have authorized the user to perform a specific action, we can execute the request using `callWithInternalUser`.

docs/developer/best-practices/typescript.asciidoc

@@ -47,7 +47,7 @@ Additionally, in order to migrate into project refs, you also need to make sure
     "declarationMap": true
   },
   "include": [
-    // add all the folders containg files to be compiled
+    // add all the folders containing files to be compiled
   ],
   "references": [
     { "path": "../../core/tsconfig.json" },

docs/developer/contributing/development-ci-metrics.asciidoc

@@ -67,7 +67,7 @@ You can report new metrics by using the `CiStatsReporter` class provided by the
 
 In order to prevent the page load bundles from growing unexpectedly large we limit the `page load asset size` metric for each plugin. When a PR increases this metric beyond the limit defined for that plugin in {kib-repo}blob/{branch}/packages/kbn-optimizer/limits.yml[`limits.yml`] a failed commit status is set and the PR author needs to decide how to resolve this issue before the PR can be merged.
 
-In most cases the limit should be high enough that PRs shouldn't trigger overages, but when they do make sure it's clear what is cuasing the overage by trying the following:
+In most cases the limit should be high enough that PRs shouldn't trigger overages, but when they do make sure it's clear what is causing the overage by trying the following:
 
 1. Run the optimizer locally with the `--profile` flag to produce webpack `stats.json` files for bundles which can be inspected using a number of different online tools. Focus on the chunk named `{pluginId}.plugin.js`; the `*.chunk.js` chunks make up the `async chunks size` metric which is currently unlimited and is the main way that we <<plugin-performance, reduce the size of page load chunks>>.
 +
@@ -107,7 +107,7 @@ prettier -w {pluginDir}/target/public/{pluginId}.plugin.js
 
 Once you've identified the files which were added to the build you likely just need to stick them behind an async import as described in <<plugin-performance, Plugin performance>>.
 
-In the case that the bundle size is not being bloated by anything obvious, but it's still larger than the limit, you can raise the limit in your PR. Do this either by editting the {kib-repo}blob/{branch}/packages/kbn-optimizer/limits.yml[`limits.yml` file] manually or by running the following to have the limit updated to the current size + 15kb
+In the case that the bundle size is not being bloated by anything obvious, but it's still larger than the limit, you can raise the limit in your PR. Do this either by editing the {kib-repo}blob/{branch}/packages/kbn-optimizer/limits.yml[`limits.yml` file] manually or by running the following to have the limit updated to the current size + 15kb
 
 [source,shell]
 -----------

docs/developer/contributing/development-functional-tests.asciidoc

@@ -185,8 +185,8 @@ node scripts/functional_test_runner --config test/functional/config.firefox.js
 [discrete]
 ==== Using the test_user service
 
-Tests should run at the positive security boundry condition, meaning that they should be run with the mimimum privileges required (and documented) and not as the superuser.
- This prevents the type of regression where additional privleges accidentally become required to perform the same action. 
+Tests should run at the positive security boundary condition, meaning that they should be run with the minimum privileges required (and documented) and not as the superuser.
+ This prevents the type of regression where additional privileges accidentally become required to perform the same action. 
 
 The functional UI tests now default to logging in with a user named `test_user` and the roles of this user can be changed dynamically without logging in and out.  
 
@@ -458,7 +458,7 @@ Bad example: `PageObjects.app.clickButton()`
 class AppPage {
   // what can people who call this method expect from the
   // UI after the promise resolves? Since the reaction to most
-  // clicks is asynchronous the behavior is dependant on timing
+  // clicks is asynchronous the behavior is dependent on timing
   // and likely to cause test that fail unexpectedly
   async clickButton () {
     await testSubjects.click(‘menuButton’);

docs/developer/contributing/development-tests.asciidoc

@@ -51,7 +51,7 @@ Any additional options supplied to `test:jest` will be passed onto the Jest CLI
 ----
 kibana/src/plugins/dashboard/server$ yarn test:jest --coverage
 
-# is equivelant to
+# is equivalent to
 
 yarn jest --coverage --verbose --config /home/tyler/elastic/kibana/src/plugins/dashboard/jest.config.js server
 ----

docs/developer/plugin/migrating-legacy-plugins-examples.asciidoc

@@ -486,7 +486,7 @@ to change the application or the navlink state at runtime.
 
 [source,typescript]
 ----
-// my_plugin has a required dependencie to the `licensing` plugin
+// my_plugin has a required dependency to the `licensing` plugin
 interface MyPluginSetupDeps {
   licensing: LicensingPluginSetup;
 }

docs/development/core/public/kibana-plugin-core-public.appnavoptions.euiicontype.md

@@ -4,7 +4,7 @@
 
 ## AppNavOptions.euiIconType property
 
-A EUI iconType that will be used for the app's icon. This icon takes precendence over the `icon` property.
+A EUI iconType that will be used for the app's icon. This icon takes precedence over the `icon` property.
 
 <b>Signature:</b>
 

docs/development/core/public/kibana-plugin-core-public.appnavoptions.md

@@ -16,7 +16,7 @@ export interface AppNavOptions
 
 |  Property | Type | Description |
 |  --- | --- | --- |
-|  [euiIconType](./kibana-plugin-core-public.appnavoptions.euiicontype.md) | <code>string</code> | A EUI iconType that will be used for the app's icon. This icon takes precendence over the <code>icon</code> property. |
+|  [euiIconType](./kibana-plugin-core-public.appnavoptions.euiicontype.md) | <code>string</code> | A EUI iconType that will be used for the app's icon. This icon takes precedence over the <code>icon</code> property. |
 |  [icon](./kibana-plugin-core-public.appnavoptions.icon.md) | <code>string</code> | A URL to an image file used as an icon. Used as a fallback if <code>euiIconType</code> is not provided. |
 |  [order](./kibana-plugin-core-public.appnavoptions.order.md) | <code>number</code> | An ordinal used to sort nav links relative to one another for display. |
 |  [tooltip](./kibana-plugin-core-public.appnavoptions.tooltip.md) | <code>string</code> | A tooltip shown when hovering over app link. |

docs/development/core/public/kibana-plugin-core-public.httpsetup.fetch.md

@@ -4,7 +4,7 @@
 
 ## HttpSetup.fetch property
 
-Makes an HTTP request. Defaults to a GET request unless overriden. See [HttpHandler](./kibana-plugin-core-public.httphandler.md) for options.
+Makes an HTTP request. Defaults to a GET request unless overridden. See [HttpHandler](./kibana-plugin-core-public.httphandler.md) for options.
 
 <b>Signature:</b>
 

docs/development/core/public/kibana-plugin-core-public.httpsetup.md

@@ -19,7 +19,7 @@ export interface HttpSetup
 |  [basePath](./kibana-plugin-core-public.httpsetup.basepath.md) | <code>IBasePath</code> | APIs for manipulating the basePath on URL segments. See [IBasePath](./kibana-plugin-core-public.ibasepath.md) |
 |  [delete](./kibana-plugin-core-public.httpsetup.delete.md) | <code>HttpHandler</code> | Makes an HTTP request with the DELETE method. See [HttpHandler](./kibana-plugin-core-public.httphandler.md) for options. |
 |  [externalUrl](./kibana-plugin-core-public.httpsetup.externalurl.md) | <code>IExternalUrl</code> |  |
-|  [fetch](./kibana-plugin-core-public.httpsetup.fetch.md) | <code>HttpHandler</code> | Makes an HTTP request. Defaults to a GET request unless overriden. See [HttpHandler](./kibana-plugin-core-public.httphandler.md) for options. |
+|  [fetch](./kibana-plugin-core-public.httpsetup.fetch.md) | <code>HttpHandler</code> | Makes an HTTP request. Defaults to a GET request unless overridden. See [HttpHandler](./kibana-plugin-core-public.httphandler.md) for options. |
 |  [get](./kibana-plugin-core-public.httpsetup.get.md) | <code>HttpHandler</code> | Makes an HTTP request with the GET method. See [HttpHandler](./kibana-plugin-core-public.httphandler.md) for options. |
 |  [head](./kibana-plugin-core-public.httpsetup.head.md) | <code>HttpHandler</code> | Makes an HTTP request with the HEAD method. See [HttpHandler](./kibana-plugin-core-public.httphandler.md) for options. |
 |  [options](./kibana-plugin-core-public.httpsetup.options.md) | <code>HttpHandler</code> | Makes an HTTP request with the OPTIONS method. See [HttpHandler](./kibana-plugin-core-public.httphandler.md) for options. |

docs/development/core/server/kibana-plugin-core-server.md

@@ -303,7 +303,7 @@ The plugin integrates with the core system via lifecycle events: `setup`<!-- -->
 |  [SavedObjectAttributeSingle](./kibana-plugin-core-server.savedobjectattributesingle.md) | Don't use this type, it's simply a helper type for [SavedObjectAttribute](./kibana-plugin-core-server.savedobjectattribute.md) |
 |  [SavedObjectMigrationFn](./kibana-plugin-core-server.savedobjectmigrationfn.md) | A migration function for a [saved object type](./kibana-plugin-core-server.savedobjectstype.md) used to migrate it to a given version |
 |  [SavedObjectSanitizedDoc](./kibana-plugin-core-server.savedobjectsanitizeddoc.md) | Describes Saved Object documents that have passed through the migration framework and are guaranteed to have a <code>references</code> root property. |
-|  [SavedObjectsClientContract](./kibana-plugin-core-server.savedobjectsclientcontract.md) | Saved Objects is Kibana's data persisentence mechanism allowing plugins to use Elasticsearch for storing plugin state.<!-- -->\#\# SavedObjectsClient errors<!-- -->Since the SavedObjectsClient has its hands in everything we are a little paranoid about the way we present errors back to to application code. Ideally, all errors will be either:<!-- -->1. Caused by bad implementation (ie. undefined is not a function) and as such unpredictable 2. An error that has been classified and decorated appropriately by the decorators in [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md)<!-- -->Type 1 errors are inevitable, but since all expected/handle-able errors should be Type 2 the <code>isXYZError()</code> helpers exposed at <code>SavedObjectsErrorHelpers</code> should be used to understand and manage error responses from the <code>SavedObjectsClient</code>.<!-- -->Type 2 errors are decorated versions of the source error, so if the elasticsearch client threw an error it will be decorated based on its type. That means that rather than looking for <code>error.body.error.type</code> or doing substring checks on <code>error.body.error.reason</code>, just use the helpers to understand the meaning of the error:<!-- -->\`\`\`<!-- -->js if (SavedObjectsErrorHelpers.isNotFoundError(error)) { // handle 404 }<!-- -->if (SavedObjectsErrorHelpers.isNotAuthorizedError(error)) { // 401 handling should be automatic, but in case you wanted to know }<!-- -->// always rethrow the error unless you handle it throw error; \`\`\`<!-- -->\#\#\# 404s from missing index<!-- -->From the perspective of application code and APIs the SavedObjectsClient is a black box that persists objects. One of the internal details that users have no control over is that we use an elasticsearch index for persistance and that index might be missing.<!-- -->At the time of writing we are in the process of transitioning away from the operating assumption that the SavedObjects index is always available. Part of this transition is handling errors resulting from an index missing. These used to trigger a 500 error in most cases, and in others cause 404s with different error messages.<!-- -->From my (Spencer) perspective, a 404 from the SavedObjectsApi is a 404; The object the request/call was targeting could not be found. This is why \#14141 takes special care to ensure that 404 errors are generic and don't distinguish between index missing or document missing.<!-- -->See [SavedObjectsClient](./kibana-plugin-core-server.savedobjectsclient.md) See [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md) |
+|  [SavedObjectsClientContract](./kibana-plugin-core-server.savedobjectsclientcontract.md) | Saved Objects is Kibana's data persisentence mechanism allowing plugins to use Elasticsearch for storing plugin state.<!-- -->\#\# SavedObjectsClient errors<!-- -->Since the SavedObjectsClient has its hands in everything we are a little paranoid about the way we present errors back to to application code. Ideally, all errors will be either:<!-- -->1. Caused by bad implementation (ie. undefined is not a function) and as such unpredictable 2. An error that has been classified and decorated appropriately by the decorators in [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md)<!-- -->Type 1 errors are inevitable, but since all expected/handle-able errors should be Type 2 the <code>isXYZError()</code> helpers exposed at <code>SavedObjectsErrorHelpers</code> should be used to understand and manage error responses from the <code>SavedObjectsClient</code>.<!-- -->Type 2 errors are decorated versions of the source error, so if the elasticsearch client threw an error it will be decorated based on its type. That means that rather than looking for <code>error.body.error.type</code> or doing substring checks on <code>error.body.error.reason</code>, just use the helpers to understand the meaning of the error:<!-- -->\`\`\`<!-- -->js if (SavedObjectsErrorHelpers.isNotFoundError(error)) { // handle 404 }<!-- -->if (SavedObjectsErrorHelpers.isNotAuthorizedError(error)) { // 401 handling should be automatic, but in case you wanted to know }<!-- -->// always rethrow the error unless you handle it throw error; \`\`\`<!-- -->\#\#\# 404s from missing index<!-- -->From the perspective of application code and APIs the SavedObjectsClient is a black box that persists objects. One of the internal details that users have no control over is that we use an elasticsearch index for persistence and that index might be missing.<!-- -->At the time of writing we are in the process of transitioning away from the operating assumption that the SavedObjects index is always available. Part of this transition is handling errors resulting from an index missing. These used to trigger a 500 error in most cases, and in others cause 404s with different error messages.<!-- -->From my (Spencer) perspective, a 404 from the SavedObjectsApi is a 404; The object the request/call was targeting could not be found. This is why \#14141 takes special care to ensure that 404 errors are generic and don't distinguish between index missing or document missing.<!-- -->See [SavedObjectsClient](./kibana-plugin-core-server.savedobjectsclient.md) See [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md) |
 |  [SavedObjectsClientFactory](./kibana-plugin-core-server.savedobjectsclientfactory.md) | Describes the factory used to create instances of the Saved Objects Client. |
 |  [SavedObjectsClientFactoryProvider](./kibana-plugin-core-server.savedobjectsclientfactoryprovider.md) | Provider to invoke to retrieve a [SavedObjectsClientFactory](./kibana-plugin-core-server.savedobjectsclientfactory.md)<!-- -->. |
 |  [SavedObjectsClientWrapperFactory](./kibana-plugin-core-server.savedobjectsclientwrapperfactory.md) | Describes the factory used to create instances of Saved Objects Client Wrappers. |