docs: spelling corrections (#2002)

Author: 10xLaCroixDrinker

GUIDELINES.md

@@ -1,6 +1,6 @@
 # Instrumentations Implementation Guide
 
-This document captures general guidelines for implementing instrumentations in NodeJS and browser.
+This document captures general guidelines for implementing instrumentations in Node.js and browser.
 
 ## Types
 
@@ -14,11 +14,11 @@ These typescript `interface`s, `type`s, `enum`s and js `const`ants statements SH
 
 #### Exporting
 
-All types from `types.ts` file MUST be exported from instrumentation `index.ts` using export statement `export * from './types'`, which guarentee that they publicly available.
+All types from `types.ts` file MUST be exported from instrumentation `index.ts` using export statement `export * from './types'`, which guarantee that they publicly available.
 
 #### Breaking Changes
 
-Since these types are publicly exported, a breaking change in this file can cause transpilation issues or require code changes for existing users. Special care and attention should be put when modifiying this file to guarantee backword compatibility or proper documentation of breaking changes.
+Since these types are publicly exported, a breaking change in this file can cause transpilation issues or require code changes for existing users. Special care and attention should be put when modifying this file to guarantee backward compatibility or proper documentation of breaking changes.
 
 ### Internal Types
 
@@ -30,15 +30,15 @@ It is sometimes convenient to place these declarations in a dedicated file which
 
 The file SHOULD be named `internal-types.ts`.
 
-Using this file is optional - when a type is used only in a single file, it is ok to declare it and use it in this file **without exporting it**. When a type is expected to be shared between multiple files, it is encourged to be declared in `internal-types.ts` to prevent circular dependencies.
+Using this file is optional - when a type is used only in a single file, it is ok to declare it and use it in this file **without exporting it**. When a type is expected to be shared between multiple files, it is encouraged to be declared in `internal-types.ts` to prevent circular dependencies.
 
 #### Exporting
 
-This file MUST NOT be exported publicly from instrumentation package, not directly (via `index.ts`) and not transitivly via export of other files.
+This file MUST NOT be exported publicly from instrumentation package, not directly (via `index.ts`) and not transitively via export of other files.
 
 #### Changes
 
-Since the declarations in this file are not exported in the public instrumentation api, it is allowed to apply any refactors to this file, and they will not be breaking changes to users.
+Since the declarations in this file are not exported in the public instrumentation API, it is allowed to apply any refactors to this file, and they will not be breaking changes to users.
 
 ## Dependencies
 
@@ -48,7 +48,7 @@ Since instrumentations will install all their dependencies into the end user `no
 
 ### OpenTelemetry API
 
-Instrumentation SHOULD NOT add a dependency on `@opentelemetry/api`, as using multiple instrumentations might install multiple api versions into the user node_modules directory. It SHOULD add an entry in `"peerDependencies"` in `package.json` with the **minimum** api version it requires, as caret range (for example: `^1.0.0`).
+Instrumentation SHOULD NOT add a dependency on `@opentelemetry/api`, as using multiple instrumentations might install multiple API versions into the user node_modules directory. It SHOULD add an entry in `"peerDependencies"` in `package.json` with the **minimum** API version it requires, as caret range (for example: `^1.0.0`).
 
 Users and distributions need to install a version of `@opentelemetry/api` that is compatible with the instrumentation to use it.
 
@@ -64,14 +64,14 @@ Instrumentations SHOULD NOT add a `"dependency"` or `"peerDependencies"` on the
 
 This means that the instrumentation code SHOULD NOT `import` anywhere from the instrumented package. e.g. `@opentelemetry/instrumentation-foo` cannot `import 'foo'` as it will fail for applications that installed the instrumentation but not the `foo` package itself, which is a valid and supported use case for OpenTelemetry distributions and end users.
 
-It is allowed, however, to import `types`  from the instrumented package with the [`import type`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export) syntax, as long as this type is not used in the public api:
+It is allowed, however, to import `types`  from the instrumented package with the [`import type`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export) syntax, as long as this type is not used in the public API:
 
 ```js
 // instrumentation.ts
 import type { Bar } from 'foo'; // OK
 ```
 
-Since the instrumented package is installed as a dev dependency, types are available during compiling. Since they are not part of the public api, typescript removes these imports from the build artifacts during transpilation.
+Since the instrumented package is installed as a dev dependency, types are available during compiling. Since they are not part of the public API, typescript removes these imports from the build artifacts during transpilation.
 
 ### Types Public API
 
@@ -89,7 +89,7 @@ Note that types that are used in non-public files (like `internal-types.ts` or `
 
 ### Adding Types in Public API
 
-Sometimes, instrumented package types are needed in an instrumentation's public api. These are mostly found in `types.ts` file on instrumentation config hooks that include data from the package and want to type it for consumers.
+Sometimes, instrumented package types are needed in an instrumentation's public API. These are mostly found in `types.ts` file on instrumentation config hooks that include data from the package and want to type it for consumers.
 
 To support this use case, you can choose one of the following options:
 

README.md

@@ -36,7 +36,7 @@
 
 ---
 
-# OpenTelemetry Javascript Contrib
+# OpenTelemetry JavaScript Contrib
 
 A repository for OpenTelemetry JavaScript contributions that are not part of the [core repository](https://github.com/open-telemetry/opentelemetry-js) and core distribution of the API and the SDK.
 

detectors/node/opentelemetry-resource-detector-aws/test/detectors/AwsEcsDetector.test.ts

@@ -199,7 +199,7 @@ describe('AwsEcsResourceDetector', () => {
       process.env.ECS_CONTAINER_METADATA_URI_V4 = ECS_CONTAINER_METADATA_URI_V4;
     });
 
-    describe('when succesfully retrieving the data', () => {
+    describe('when successfully retrieving the data', () => {
       function generateLaunchTypeTests(
         resourceAttributes: EcsResourceAttributes,
         suffix = ''

detectors/node/opentelemetry-resource-detector-aws/test/detectors/AwsEksDetector.test.ts

@@ -246,7 +246,7 @@ describe('awsEksDetector', () => {
     });
   });
 
-  describe('on unsuccesful request', () => {
+  describe('on unsuccessful request', () => {
     it('should return an empty resource when timed out', async () => {
       fileStub = sinon
         .stub(AwsEksDetector, 'fileAccessAsync' as any)

detectors/node/opentelemetry-resource-detector-container/README.md

@@ -28,7 +28,7 @@ const tracerProvider = new NodeTracerProvider({ resource });
 
 ## Available detectors
 
-- `containerDetector`: Populates `container.id` for processes running on contianers supporting : docker( cgroup v1 or v2 ) or with containerd
+- `containerDetector`: Populates `container.id` for processes running on containers supporting : docker( cgroup v1 or v2 ) or with containerd
 
 ## Useful links
 

detectors/node/opentelemetry-resource-detector-github/README.md

@@ -35,7 +35,7 @@ run()
 
 ## Useful links
 
-- [GitHub Action Enviornment Variables](https://docs.github.com/en/free-pro-team@latest/actions/reference/environment-variables)
+- [GitHub Action Environment Variables](https://docs.github.com/en/free-pro-team@latest/actions/reference/environment-variables)
 - For more information on OpenTelemetry, visit: <https://opentelemetry.io/>
 - For more about OpenTelemetry JavaScript: <https://github.com/open-telemetry/opentelemetry-js>
 - For help or feedback on this project, join us in [GitHub Discussions][discussions-url]

detectors/node/opentelemetry-resource-detector-github/src/detectors/GitHubDetector.ts

@@ -49,7 +49,7 @@ class GitHubDetector implements Detector {
    * environment variables:
    * https://docs.github.com/en/free-pro-team@latest/actions/reference/environment-variables
    *
-   * If succesful it returns a promise containing a {@link Resource}
+   * If successful it returns a promise containing a {@link Resource}
    * populated with GitHub metadata. Returns a promise containing an
    * empty {@link Resource} if the connection fails.
    *

examples/express/src/server.ts

@@ -34,7 +34,7 @@ const authMiddleware: RequestHandler = (req, res, next) => {
 app.use(express.json());
 app.get('/health', (req, res) => res.status(200).send("HEALTHY")); // endpoint that is called by framework/cluster
 app.get('/run_test', async (req, res) => {
-  // Calls another endpoint of the same API, somewhat mimicing an external API call
+  // Calls another endpoint of the same API, somewhat mimicking an external API call
   const createdCat = await axios.post(`http://localhost:${PORT}/cats`, {
     name: 'Tom',
     friends: [

examples/react-load/preact/README.md

@@ -3,7 +3,7 @@
 The React Load plugin provides auto-instrumentation for react lifecycle methods.
 This example uses the plugin and exports them to the console.
 
-The example will show traces belong to the mounting, updating, and umounting flows as defined by React 16.4+. In this example we can show how this plugin can also be used in a Preact app.
+The example will show traces belong to the mounting, updating, and unmounting flows as defined by React 16.4+. In this example we can show how this plugin can also be used in a Preact app.
 
 ## Installation
 

examples/react-load/react/README.md

@@ -3,7 +3,7 @@
 The React Load plugin provides auto-instrumentation for react lifecycle methods.
 This example uses the plugin and exports them to the console.
 
-The example will show traces belong to the mounting, updating, and umounting flows as defined by React 16.4+.
+The example will show traces belong to the mounting, updating, and unmounting flows as defined by React 16.4+.
 
 ## Installation