chore: multiple grammar or wording fixes (#162)

Author: Cadienvan

docs/development/accessibility.md

@@ -59,7 +59,7 @@ Developers may also use pre-made components with accessibility features built in
 
 Users should make sure to read and understand the accessibility documentation for pre-made components.
 It is also best practice to incorporate testing of your application with common
-assisitive technologies like screen readers and limiting input to keyboard interaction. See [tooling](#tooling) below.
+assistive technologies like screen readers and limiting input to keyboard interaction. See [tooling](#tooling) below.
 
 For those working on Linux
 [List Of Accessibility Documentation Sources And Tools (For GNU/Linux Development And Testing)](https://desktopqe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com:3200/desktopqe/d06-projects/a11y.A11y_devel_doc_sources.html)
@@ -76,7 +76,7 @@ reference for working with the guidelines. The [WAI-ARIA Authoring Practices Exa
 
 In the teams experience testing/validation of accessibility requirements will be
 against the front-end and not the APIs provided by the Node.js back-end. The result
-being that team members building the front-end must be knowleadgeable on
+being that team members building the front-end must be knowledgeable on
 accessibility requirements. Back-end Node.js developers, on the other hand, will support
 requirements that come from the front-end versus driving the accessibility effort.
 
@@ -104,7 +104,7 @@ accessibility testing.
 Command line tools have been historically considered more accessible (see
 [Accessibility of Command Line Interfaces](https://dl.acm.org/doi/fullHtml/10.1145/3411764.3445544)
 for discussion on this topic).
-For this reason, most if not all of accessibility standards and guidlines are for
+For this reason, most if not all of accessibility standards and guidelines are for
 graphical user interfaces. The team is not aware of standards or guidelines that
 provide guidance specifically for command line applications. 
 
@@ -128,7 +128,7 @@ include:
 
 Accessibility tooling is generally not Node.js specific. However some tools are
 built in Node.js and are delivered through npm. They will, therefore, fit easily in a JavaScript
-or Node.js workflow when nessary. For example:
+or Node.js workflow when necessary. For example:
 * [eslint-plugin-jsx-a11y](https://www.npmjs.com/package/eslint-plugin-jsx-a11y)
 * [axe-core](https://www.npmjs.com/package/axe-core)
 * [pa11y](https://www.npmjs.com/package/pa11y)

docs/development/building-good-containers.md

@@ -60,7 +60,7 @@ as not being able use the `NODE_EXTRA_CA_CERTS` environment
 variable. You can read more about the issue
 [here](https://github.com/nodejs/node/pull/37727).
 
-Typical work arounds which include using firewall functionality to
+Typical workarounds which include using firewall functionality to
 proxy ports most often don't work in containers as the firewall
 capability is often not included in container distributions.
 

docs/development/ci-cd.md

@@ -18,7 +18,7 @@ existing Node.js image (for example)
 [ubi8/nodejs-16](https://catalog.redhat.com/software/containers/ubi8/nodejs-16/615aee9fc739c0a4123a87e1)
 image or a [dependency image](./building-good-containers.md#dependency-image).
 
-While a Node.js developer may not need to setup the CI/CD pipleline a
+While a Node.js developer may not need to setup the CI/CD pipeline a
 good understanding of their organizations pipeline is often valuable
 in order to understand what's needed to externalize configuration in
 the code they write as well as being able to investigate problems that
@@ -30,7 +30,7 @@ N/A
 
 ## Guidance
 
-The team's experiece is that there are most often two different ci/cd flows
+The team's experience is that there are most often two different ci/cd flows
 which are used at the same time:
 
 * Testing on code check-in
@@ -55,7 +55,7 @@ for this kind of testing for Node.js components are captured in the
 [Code Consistency](./code-consistency.md),
 [Testing](./testing.md), and
 [Code Coverage](./code-coverage.md) sections. Teams often
-then also test the PR by spinning up a container environment and runing some
+then also test the PR by spinning up a container environment and running some
 initial integration test.  If you run check-in integration tests it is often useful to run both 
 integration and unit tests in the container in order to capture a more complete picture
 of the Code Coverage achieved.
@@ -84,15 +84,15 @@ support a number of stages/environments including:
 
 * Development
   * This environment often mirrors the main branch of each component
-    and may sometimes not be working due to mistmatches in APIs/use of APIs.
+    and may sometimes not be working due to mismatches in APIs/use of APIs.
   * Once tests pass in development, PRs may be automatically opened to
     update Staging to the new component levels.
 * Staging
   * Staging uses tagged versions of each component which are known to
     work together.
   * They may be multiple staging environments. One which
     mirrors production in terms of non-application components
-    (versions of istio, kubernetes, etc.) and additional
+    (versions of Istio, Kubernetes, etc.) and additional
     environments which reflect future target configurations
     for these components.
  * PRs may be automatically created to update component versions in
@@ -125,13 +125,13 @@ configuration for how to connect to databases and other services, the
 Node.js run configuration (production/development) and any other configuration
 information.
 
-[Jekins](https://www.jenkins.io/) and
+[Jenkins](https://www.jenkins.io/) and
 [Tekton Pipelines](https://tekton.dev/) are common tools that have been
 used by the team to implement the container pipeline.
 
 The team has found that it is advisable to use a separate git repository/branch
 to configure the versions of the components to be tested in each environment
-within the container pipeline. One commmon pattern the team has seen is using
+within the container pipeline. One common pattern the team has seen is using
 helm charts within this repo to configure the versions of the components used
 along with the configuration required for a given environment.
 
@@ -149,11 +149,11 @@ The benefit of running in the check-in tests helps developers validate that
 they have resolved reported issue.
 deploys checks in both the check-in tests as well as the container pipeline.
 
-Tools like [mend](https://www.mend.io/), [Synk](https://snyk.io/) and those
+Tools like [mend](https://www.mend.io/), [Snyk](https://snyk.io/) and those
 built into GitHub have been used for scanning in the check-in phase. Often
-a number of differents scans are required to cover all of the important aspects
+a number of different scans are required to cover all of the important aspects
 which include scans of:
-* application depencencies for vulnerabilities
+* application dependencies for vulnerabilities
 * os packages for vulnerabilities
 * source code using static analysis
 * container images for best practices (not running as root etc.)

docs/development/code-coverage.md

@@ -51,7 +51,7 @@ Code coverage should never block a production deployment
 
 ## Output Formats
 
-A common output format is the lcov format, which the recommeneded modules can produce.
+A common output format is the lcov format, which the recommended modules can produce.
 
 [jest]: https://www.npmjs.com/package/jest
 [nyc]: https://www.npmjs.com/package/nyc

docs/development/cross-origin.md

@@ -7,7 +7,7 @@ There are two patterns that the team is familiar with when dealing with Cross Or
 
 ## Cross Origin Resource Sharing (CORS)
 
-By default, browers assume that your backend server doesn't want to share its resources with a front-end that it doesn't know about.
+By default, browsers assume that your backend server doesn't want to share its resources with a front-end that it doesn't know about.
 
 You might have seen this error in the browsers dev console:
 
@@ -21,7 +21,7 @@ However, there are certain situations where your backend might want to be access
 
 When developing a backend with a public API and you would like to control access to certain resources and how they are used, CORS should be enabled.
 
-**note: When enabling CORS, it is important to limit those methods and headers your application allows to prevent unwanted actors from accessesing resources they shouldn't be accessing.**
+**note: When enabling CORS, it is important to limit those methods and headers your application allows to prevent unwanted actors from accessing resources they shouldn't be accessing.**
 
 
 ### Access to Multiple Environments

docs/development/dependencies.md

@@ -43,14 +43,14 @@ Based on the teams experience we recommend the following:
     [Canary in the Gold Mine](https://github.com/nodejs/citgm)?
   * If the dependency is a native module does it use Node-API (use
     of Node-API means that packages can work across Node.js major versions)
-* Only use dependencies with licences acceptable to your organization
+* Only use dependencies with licenses acceptable to your organization
 * When choosing to use dependencies with a lower level of use in the 
   ecosystem doing a code review to look for red flags can be useful.
 
 When evaluating dependencies, the teams typically evaluate the top level
 dependencies versus the full tree **EXCEPT** for the following in which
 we evaluate the full tree:
-* Licence Checks
+* License Checks
 * Security vulnerabilities (CVEs)
 Total number of sub-dependencies
 

docs/development/dev-flows.md

@@ -1,7 +1,7 @@
 # Typical Development Workflows
 
-Developement flows within the team's developer and the customers the team works
-with need to accomodate the following:
+Development flows within the team's developer and the customers the team works
+with need to accommodate the following:
 
 * the end target/deployment artifact is most often a container
 * for some platforms, deployment remains a server or virtual machine
@@ -120,7 +120,7 @@ Disadvantages:
 
 ## Zero install development environment
 
-Developers use a virtualized remote enviroment and use their local laptop
+Developers use a virtualized remote environment and use their local laptop
 only as a thin client.
 
 This model is typically an extension to one of the other

docs/development/kubernetes-dev-environment.md

@@ -1,7 +1,7 @@
 # Kubernetes-based Development Environment Recommendations
 
-Developement and local-testing flows should ideally be the same for all the developers of a project, but its
-common for developers on a team to have heterogeneus development platforms (i.e. Linux, Intel-based MacOS, M1-based MacOS, Windows).
+Development and local-testing flows should ideally be the same for all the developers of a project, but its
+common for developers on a team to have heterogenous development platforms (i.e. Linux, Intel-based MacOS, M1-based MacOS, Windows).
 Using kubernetes as a homogenized execution/configuration layer can be key to ensure testing/deployment
 use the same configuration settings for all developers.  Building a docker image is the same "docker build ..." command
 regardless of development platform, and kubernetes configuration settings, ideally built through yaml configuration files and 
@@ -50,7 +50,7 @@ If possible, avoid using shared databases and use local k8s deployments of the d
 developers. As long as you are careful to make sure your development zone does not contain customer data, then making backups of your 
 development databases and loading those backups in local development copies can help speed up your testcase creation process and 
 leverage "end to end" tests that may use such data.  It's common to use public helm charts (or make a copy of them) to deploy these
-databases in your local or CICD environments.  Example charts:
+databases in your local or CI/CD environments.  Example charts:
  * Minio to locally replicate S3 APIs and storage: https://github.com/minio/minio/tree/master/helm/minio
  * A huge selection of others can be found from Bitnami's collection at https://github.com/bitnami/charts/tree/main/bitnami
 
@@ -118,13 +118,13 @@ So just like how debugger flags and nodemon can be conditionally turned on in a
 integration test run.  When doing this, one should run nyc around the execution of the unit + integration tests to capture the code 
 coverage from the combination of the two types of tests.  However, one can't have the pod test-script immediately finish once the test 
 finishes, or else the test results will disappear when the test pod shuts down.  Normally, local developer testing can then just look at 
-the logs of the shutdown pod to see if it was successful or not, but when debugging failures in a CICD pipeline like Travis/Jenkins, its 
+the logs of the shutdown pod to see if it was successful or not, but when debugging failures in a CI/CD pipeline like Travis/Jenkins, its 
 very useful to run the same logic locally on one's development system, and those flows will typically need the full test result files.
 
 There are two general solutions for this:
 * For tests run in a non-production environment like minikube, a kubernetes Physical Volume (PV) can be created and
 and mounted in the test container for the post-test script to copy its result files into.  The higher level test-logic flow on one's
-development system (or CICD engine like Travis/Jenkins) can then copy out the test result and coverage files. 
+development system (or CI/CD engine like Travis/Jenkins) can then copy out the test result and coverage files. 
 
 * Utilize a state-handshake between the high level test scripting (eg. Travis/Jenkins/laptop shell) and the process in the
 test pod.  This can be done with a file in the pod, where the test scripting writes the process return-code from the tests to that file and

docs/development/mono-repository.md

@@ -65,7 +65,7 @@ While there are a benefits, there are challenges to overcome.
 * Detecting what to build. Build times can be long due to overbuilding the entire repository
 * Long build times. Because of having to build the entire repository, this will cause build times to increase because tooling no longer is just building one artifact/package, but many different ones.
 * Not just JavaScript. A monorepo may not just be JavaScript, and can impact organization, tooling, and how to approach building different artifacts or packages in different languages.
-* Git repositories can grow larger in size.  Since we are building and maintaing different packages in a singular repository, we can exponentially grow the size of the git repository.
+* Git repositories can grow larger in size.  Since we are building and maintaining different packages in a singular repository, we can exponentially grow the size of the git repository.
 * Commit messages can be harder to interpret due to multiple artifacts, packages, or teams.
 
 

docs/development/npm-package-development.md

@@ -89,9 +89,9 @@ to the public npm registry
 
 * **private** - This field is only recommended and should be set to `yes` if your package will not be published to npm.
 
-* **support** - This field is to help package maintainers communicate with and set expectations for their users about the level of support they are willing to provide on a package.  The team has worked closely with the [Node.js Package Maintence Team](https://github.com/nodejs/package-maintenance) on their recommendations on what this support field should look like.  For one of your modules, [opossum](https://github.com/nodeshift/opossum), we [set this field](https://github.com/nodeshift/opossum/blob/main/package.json#L75) to `true` and supplied our support information in a separate [package-support.json file](https://github.com/nodeshift/opossum/blob/main/package-support.json).
+* **support** - This field is to help package maintainers communicate with and set expectations for their users about the level of support they are willing to provide on a package.  The team has worked closely with the [Node.js Package Maintenance Team](https://github.com/nodejs/package-maintenance) on their recommendations on what this support field should look like.  For one of your modules, [opossum](https://github.com/nodeshift/opossum), we [set this field](https://github.com/nodeshift/opossum/blob/main/package.json#L75) to `true` and supplied our support information in a separate [package-support.json file](https://github.com/nodeshift/opossum/blob/main/package-support.json).
 
-  For more information on the support field, check out what the [Package Maintence Team says](https://github.com/nodejs/package-maintenance/blob/main/docs/PACKAGE-SUPPORT.md)
+  For more information on the support field, check out what the [Package Maintenance Team says](https://github.com/nodejs/package-maintenance/blob/main/docs/PACKAGE-SUPPORT.md)
 
 * **type** - This field defines the module format that Node.js will use.  For ES Modules(ESM), use `module` and for Common JS(CJS) modules, use `commonjs`.  For more information on how Node.js determines the difference between ESM and CJS modules take a [look at the Node.js official docs here](https://nodejs.org/dist/latest-v18.x/docs/api/packages.html#determining-module-system)
 
@@ -105,9 +105,9 @@ While there is no list of development dependencies that the team recommends, we
 
 For the teams guidance on choosing dependencies, check out the [Choosing and vetting dependencies](./dependencies.md).
 
-During development of a pacakge, it is helpful to add the package-lock.json to source control, so all developers working on the package will be able to install the same versions of dependencies.
+During development of a package, it is helpful to add the package-lock.json to source control, so all developers working on the package will be able to install the same versions of dependencies.
 
-It is also recommended to know what semver range you are specifying for any dependecy you wish to install.  For example:
+It is also recommended to know what semver range you are specifying for any dependency you wish to install.  For example:
 
 The `^` will give you all the minor and patch releases when they become available.
 
@@ -123,7 +123,7 @@ npm Workspaces supports managing multiple projects within a singular top-level,
 
 ### Bundlers and Transpilers
 
-Bundlers are helpful if your package needs to be used by both Node.js and the browser.  The same codebase can be packaged for multiple platforms with a trivial amount of work by using a bundler.  [Webpack](https://webpack.js.org/) is one such bundler that the team has some familarity with.
+Bundlers are helpful if your package needs to be used by both Node.js and the browser.  The same codebase can be packaged for multiple platforms with a trivial amount of work by using a bundler.  [Webpack](https://webpack.js.org/) is one such bundler that the team has some familiarity with.
 
 For those packages being written in Typescript, you will need to use a transpiler since Node.js does not support running TypeScript natively, so it must first be transpiled to JavaScript. We recommend the `tsc` transpiler that is shipped with [typescript](https://www.npmjs.com/package/typescript). This supports both type checking and transpilation to JavaScript.