Fix typos

CHANGELOG.md

@@ -92,7 +92,7 @@ The following changes only affect people writing Yarn plugins:
 
   - Similarly, the descriptors returned by `Resolve#getResolutionDependencies` are now expected to be the result of `Configuration#normalizeDependency` calls.
 
-  - Note that this only applies to the `dependencies` field; the `peerDependencies` field is unchanged, as it must only contains semver ranges without any protocol (with an exception for `workspace:`, but that's not relevant here).
+  - Note that this only applies to the `dependencies` field; the `peerDependencies` field is unchanged, as it must only contain semver ranges without any protocol (with an exception for `workspace:`, but that's not relevant here).
 
 - The `Resolve#getResolutionDependencies` function must now return an object of arbitrary string keys and descriptor values (instead of a map with `DescriptorHash` keys). Those descriptors will be resolved and assigned to the same keys as the initial object. This change allows resolvers to wrap resolution dependencies from other resolvers, which wasn't possible before since it'd have caused the key to change.
 
@@ -607,7 +607,7 @@ yarn set version 2.3.0
 The following changes only apply to the `pnp` linker (which is the default install strategy):
 
 - The `pnpapi` module now exposes a new function called `getAllLocators` allow you to access the list of all locators in the map without having to traverse the dependency tree. This method is considered a Yarn extension, so you should check for its existence if you plan to use it in your code.
-- When using a portal to a package that had peer dependencies, Yarn would loose the information required to resolve those peer dependencies. It will now properly resolve them the same way as all other packages in the dependency tree.
+- When using a portal to a package that had peer dependencies, Yarn would lose the information required to resolve those peer dependencies. It will now properly resolve them the same way as all other packages in the dependency tree.
 
 The following changes only apply to the `node-modules` linker:
 
@@ -703,7 +703,7 @@ yarn set version 2.1.0
 
 ### Ecosystem
 
-- Packages can now declare they they *need* to be unpacked in order to be functional using the new `"preferUnplugged": true` field in the manifest. This will hurt the experience of your users (your project will be the only one that will require hard installs), so please refrain using this field unless there's no other choice.
+- Packages can now declare that they *need* to be unpacked in order to be functional using the new `"preferUnplugged": true` field in the manifest. This will hurt the experience of your users (your project will be the only one that will require hard installs), so please refrain using this field unless there's no other choice.
 
 ### New commands
 
@@ -849,9 +849,9 @@ To see a comprehensive documentation about each possible field, please check our
 
   - The `dependenciesMeta[].comment` field is expected to be a string field. Even though it isn't actually used anywhere at the moment, we suggest you to write comments regarding the reason why some packages are used here rather than anywhere else. This might prove useful for plugin authors.
 
-  - The `dependenciesMeta[].built` field is a boolean flag; setting it to `false` will cause the package manager to ignore this package when considering the list of packages that need to be built. If the project uses `enable-scripts: false`, the warning that would have traditionally been emitted will be downgraded into a simple notice. This settings is project-wide.
+  - The `dependenciesMeta[].built` field is a boolean flag; setting it to `false` will cause the package manager to ignore this package when considering the list of packages that need to be built. If the project uses `enable-scripts: false`, the warning that would have traditionally been emitted will be downgraded into a simple notice. This setting is project-wide.
 
-  - The `peerDependenciesMeta[].optional` field is a boolean flag; setting it to `true` will stop the package manager from emitting a warning when the specified peer dependency is missing (you typically want to use it if you provide optional integrations with specific third-party packages and don't want to pollute your users' installs with a bunch of irrelevant warnings). This settings is package-specific.
+  - The `peerDependenciesMeta[].optional` field is a boolean flag; setting it to `true` will stop the package manager from emitting a warning when the specified peer dependency is missing (you typically want to use it if you provide optional integrations with specific third-party packages and don't want to pollute your users' installs with a bunch of irrelevant warnings). This setting is package-specific.
 
   - The `resolutions` field no longer support the glob syntax within its patterns, as it was redundant with its own glob-less syntax and caused unnecessary confusion.
 

GOVERNANCE.md

@@ -35,7 +35,7 @@ Stewards establish the project vision, have a full control over the code and its
 - Define project direction and planning
 - Ability to decide on moderation decisions
 
-In the event a steward becomes incapacitated, they are expected to leave keys to a trustee that will transmit the rights to an new steward appointed by the core contributors through a vote.
+In the event a steward becomes incapacitated, they are expected to leave keys to a trustee that will transmit the rights to a new steward appointed by the core contributors through a vote.
 
 #### Induction
 

packages/acceptance-tests/pkg-tests-specs/sources/commands/npm/whoami.test.js

@@ -98,7 +98,7 @@ describe(`Commands`, () => {
     );
 
     test(
-      `it should thow an error when invalid auth config is found for a scope`,
+      `it should throw an error when invalid auth config is found for a scope`,
       makeTemporaryEnv({}, async ({path, run, source}) => {
         const url = await startPackageServer();
 

packages/acceptance-tests/pkg-tests-specs/sources/commands/version.test.ts

@@ -99,7 +99,7 @@ describe(`Commands`, () => {
     );
 
     test(
-      `it shouldn't immediatly increase the version number for a workspace when using --deferred`,
+      `it shouldn't immediately increase the version number for a workspace when using --deferred`,
       makeTemporaryEnv({
         version: `0.0.0`,
       }, async ({path, run, source}) => {
@@ -118,7 +118,7 @@ describe(`Commands`, () => {
     );
 
     test(
-      `it shouldn't immediatly increase the version number for a workspace when using preferDeferredVersions`,
+      `it shouldn't immediately increase the version number for a workspace when using preferDeferredVersions`,
       makeTemporaryEnv({
         version: `0.0.0`,
       }, {
@@ -139,7 +139,7 @@ describe(`Commands`, () => {
     );
 
     test(
-      `it should immediatly increase the version number for a workspace when using --immediate, even if preferDeferredVersions is set`,
+      `it should immediately increase the version number for a workspace when using --immediate, even if preferDeferredVersions is set`,
       makeTemporaryEnv({
         version: `0.0.0`,
       }, {

packages/acceptance-tests/pkg-tests-specs/sources/dragon.test.js

@@ -80,7 +80,7 @@ describe(`Dragon tests`, () => {
         //
         // A problem is when B also has peer dependencies, like in the setup described
         // above. In this case, the Yarn implementation of PnP needs to generate a virtual
-        // package for B (in order to deambiguate the dependencies), and register it while
+        // package for B (in order to disambiguate the dependencies), and register it while
         // processing A. Then later, when iterating over B, it is possible that the
         // workspace registration overwrites the previously registered virtual dependency,
         // making it unavailable whilst still being referenced in the dependencies of A.
@@ -154,7 +154,7 @@ describe(`Dragon tests`, () => {
       async ({path, run, source}) => {
         // This test assume that we have a workspace that has a dependency listed in both its
         // peer dependencies and its dev dependencies, and that it itself has a peer
-        // depencency. In those circumstances, we've had issues where the peer dependency
+        // dependency. In those circumstances, we've had issues where the peer dependency
         // wasn't being properly resolved.
 
         await xfs.mkdirpPromise(`${path}/my-workspace`);
@@ -235,7 +235,7 @@ describe(`Dragon tests`, () => {
         // depends on X which has a peer dependency, so we virtualize X and
         // modify A to point to this new package instead of the original X.
         // Then once we traverse B we check the dependencies of A, but by
-        // this time they have already been modified, leading to a boggus
+        // this time they have already been modified, leading to a bogus
         // install.
 
         await xfs.mkdirpPromise(`${path}/packages/a`);
@@ -580,7 +580,7 @@ describe(`Dragon tests`, () => {
 
           // Make sure that both the root and dragon-test-11-b have access to the same instance.
           // This is only possible with the PnP and pnpm linkers.
-          // The node-modules linker can't fullfil these requirements for aliased packages,
+          // The node-modules linker can't fulfil these requirements for aliased packages,
           // without resorting to symlinks and a layout resembling pnpm for aliased dependencies,
           // which will be too different from the classic node_modules layout for all the other dependencies.
           await expect(source(`

packages/acceptance-tests/pkg-tests-specs/sources/features/resolutionCache.test.ts

@@ -43,7 +43,7 @@ describe(`Features`, () => {
         // Now, we need a way to force the resolution cache to be used before resolving
         // a version that it isn't aware of. To that end, we create a package.json with
         // a dependency on one-fixed-dep@2, and we run 'yarn add [email protected]'. This
-        // ensure that Yarn will run getCandidate on [email protected] first (because it's
+        // ensures that Yarn will run getCandidate on [email protected] first (because it's
         // required before adding it to the package.json), and [email protected] later.
 
         await xfs.writeFilePromise(ppath.join(path, Filename.manifest), JSON.stringify({

packages/acceptance-tests/pkg-tests-specs/sources/node-modules.test.ts

@@ -708,7 +708,7 @@ describe(`Node_Modules`, () => {
 
   test(`should support dependencies hoist border`,
     // . -> workspace -> dep1 -> dep2 -> dep3
-    // should be hoised to:
+    // should be hoisted to:
     // . -> workspace -> dep1 -> dep2
     //                        -> dep3
     makeTemporaryEnv(

packages/acceptance-tests/pkg-tests-specs/sources/protocols/portals.test.js

@@ -44,7 +44,7 @@ describe(`Protocols`, () => {
     );
 
     test(
-      `it should allow portals to access their peer dependencies (single occurence)`,
+      `it should allow portals to access their peer dependencies (single occurrence)`,
       makeTemporaryEnv({
         dependencies: {
           [`no-deps`]: `1.0.0`,
@@ -67,7 +67,7 @@ describe(`Protocols`, () => {
     );
 
     test(
-      `it should allow portals to access their peer dependencies (multiple occurences)`,
+      `it should allow portals to access their peer dependencies (multiple occurrences)`,
       makeTemporaryEnv({
         dependencies: {
           [`provides-peer-deps-1-0-0`]: `file:./provides-peer-deps-1-0-0`,

packages/docusaurus/blog/2020-11-30-release-2.4.mdx

@@ -12,7 +12,7 @@ We'll try to reference external plugins made by our community in our release not
 
 For now, let me present those two:
 
-- [yarn.build](https://yarn.build/) by [ojkelly](https://twitter.com/ojkelly) is a fast monorepo builder for Yarn. In a sense it's similar to [`yarn workspaces foreach`](https://yarnpkg.com/cli/workspaces/foreach) but more opinionated, and thus easier to adapt to existing workflows. It parallelises builds, shows what's being executed, and generates zipped archives suitable for AWS and similar platforms.
+- [yarn.build](https://yarn.build/) by [ojkelly](https://twitter.com/ojkelly) is a fast monorepo builder for Yarn. In a sense it's similar to [`yarn workspaces foreach`](https://yarnpkg.com/cli/workspaces/foreach) but more opinionated, and thus easier to adapt to existing workflows. It parallelizes builds, shows what's being executed, and generates zipped archives suitable for AWS and similar platforms.
 
 - [prod-install](https://gitlab.com/Larry1123/yarn-contrib/-/tree/master/packages/plugin-production-install) by [Larry1123](https://gitlab.com/Larry1123) and [NETSVS](https://www.mynetsvs.com/) is a much more powerful version of [`yarn workspaces focus`](https://yarnpkg.com/cli/workspaces/focus) that copies the selected workspaces into a target location before transforming it to become self-sufficient - the final directory thus being ready to be efficiently cached and deployed via Docker layers.
 
@@ -26,7 +26,7 @@ We've also significantly improved the output to be more in line with the rest of
 
 ![image](https://user-images.githubusercontent.com/1037931/100546031-5ee0ba00-325f-11eb-8d6d-c6973571e099.png)
 
-This new output is compatible with the `--json` flag, meaning that you can leverage the information obtained from `yarn npm audit --json` from any script you want - even the command-line itself, using tools like [jq](https://stedolan.github.io/jq/)! 
+This new output is compatible with the `--json` flag, meaning that you can leverage the information obtained from `yarn npm audit --json` from any script you want - even the command-line itself, using tools like [jq](https://stedolan.github.io/jq/)!
 
 ## Better Warnings
 

packages/docusaurus/blog/2021-09-25-release-3.1.mdx

@@ -84,7 +84,7 @@ yarn workspaces foreach --since run eslint .
 yarn workspaces list --since
 ```
 
-The `--since` flag also accepts an optional argument (`--since=${commit-ish}`) to manually define a source from which the changes should be derived. 
+The `--since` flag also accepts an optional argument (`--since=${commit-ish}`) to manually define a source from which the changes should be derived.
 
 ### New Workspace Syntax: `workspace:^`
 

packages/docusaurus/blog/2022-02-21-release-3.2.mdx

@@ -40,7 +40,7 @@ Every version we look for little UI annoyances to fix. This time is no exception
 
 - Errors thrown when cloning Git repositories were previously reported as regular stack traces. They will now have dedicated output.
 
-![Improved Git Error](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m4zkw674viqnuqc7c8fr.png) 
+![Improved Git Error](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m4zkw674viqnuqc7c8fr.png)
 
 ## Next Major
 

packages/docusaurus/docs/advanced/03-pnp/pnp-spec.mdx

@@ -46,7 +46,7 @@ All algorithms in this specification assume that paths have been normalized acco
 
 For improved compatibility with legacy codebases, Plug'n'Play supports a feature we call "fallback". The fallback triggers when a package makes a resolution request to a dependency it doesn't list in its dependencies. In normal circumstances the resolver would throw, but when the fallback is enabled the resolver should first try to find the dependency packages amongst the dependencies of a set of special packages. If it finds it, it then returns it transparently.
 
-In a sense, the fallback can be seen as a limited and safer form of hoisting. While hoisting allows unconstrainted access through multiple levels of dependencies, the fallback requires to explicitly define a fallback package - usually the top-level one.
+In a sense, the fallback can be seen as a limited and safer form of hoisting. While hoisting allows unconstrained access through multiple levels of dependencies, the fallback requires to explicitly define a fallback package - usually the top-level one.
 
 ## Package locations
 

packages/docusaurus/docs/getting-started/extra/corepack.mdx

@@ -20,7 +20,7 @@ Corepack is marked experimental so we can iterate on its CLI faster, but it's al
 
 Corepack is included with all official Node.js releases starting from Node.js 14.19 / 16.9. It's however opt-in for the duration of the experimental stage, so you'll need to run `corepack enable` before it's active.
 
-You can quickly check whether Corepack is enabled by running `yarn exec env | grep COREPACK_ROOT`: if you get a path as output, Corepack is properly installed. If not, something may be messing with how the shims are installed. In that case check the [Troubleshooting](/corepack#troubleshooting) section for advices.
+You can quickly check whether Corepack is enabled by running `yarn exec env | grep COREPACK_ROOT`: if you get a path as output, Corepack is properly installed. If not, something may be messing with how the shims are installed. In that case check the [Troubleshooting](/corepack#troubleshooting) section for advice.
 
 :::danger
 Some third-party distributors may not include Corepack by default, in particular if you install Node.js from your system package manager. If that happens, running `npm install -g corepack` before `corepack enable` should do the trick.

packages/docusaurus/docs/getting-started/extra/questions-and-answers.mdx

@@ -130,7 +130,7 @@ Although tempting, this reasoning has a fatal flaw: removing the lockfile from t
 
 Of course these points are only part of the problem - the lack of lockfile also means that key state information are missing from the repository. When months later you or your contributors want to make a fix on one of your old projects you might not even be able to *build* it anymore, let alone improve it.
 
-Lockfiles should **always** be kept within the repository. Continuous integration testing **is a good idea**, but should be left to continuous integration systems. For example, Yarn itself runs [daily tests](https://github.com/yarnpkg/berry#current-status) against the latest versions of major open-source frameworks and tools, which allows us to quickly spot any compatibility issue with the newest release, while still being guarateed that every contributor will have a consistent experience working with the project. [Dependabot](https://dependabot.com/#how-it-works) and [Renovate](https://www.whitesourcesoftware.com/free-developer-tools/renovate) are also good tools that track your dependencies updates for you.
+Lockfiles should **always** be kept within the repository. Continuous integration testing **is a good idea**, but should be left to continuous integration systems. For example, Yarn itself runs [daily tests](https://github.com/yarnpkg/berry#current-status) against the latest versions of major open-source frameworks and tools, which allows us to quickly spot any compatibility issue with the newest release, while still being guaranteed that every contributor will have a consistent experience working with the project. [Dependabot](https://dependabot.com/#how-it-works) and [Renovate](https://www.whitesourcesoftware.com/free-developer-tools/renovate) are also good tools that track your dependencies updates for you.
 
 ## How to share scripts between workspaces?
 

packages/docusaurus/docs/getting-started/migrating/pnp.mdx

@@ -76,7 +76,7 @@ Make sure that `typescript`, `eslint`, `prettier`, ... all dependencies typicall
 2. Run `yarn dlx @yarnpkg/sdks vscode` and commit the changes.
 3. For TypeScript, don't forget to select [Use Workspace Version](https://code.visualstudio.com/docs/typescript/typescript-compiling#_using-the-workspace-version-of-typescript) in VSCode.
 
-## General Advices
+## General Advice
 
 ### Fix dependencies with `packageExtensions`
 

packages/docusaurus/src/components/StarrySky.tsx

@@ -27,7 +27,7 @@ function getPoint() {
   return {x, y, z};
 }
 
-function getRandomParticelPos(particleCount: number) {
+function getRandomParticlePos(particleCount: number) {
   const arr = new Float32Array(particleCount * 3);
 
   for (let i = 0; i < particleCount; i++) {
@@ -72,19 +72,19 @@ function installSky(canvas: HTMLCanvasElement) {
   const camera = new THREE.PerspectiveCamera(fov, aspect, near, far);
 
   // Geometry
-  const geometrys = [
+  const geometries = [
     new THREE.BufferGeometry(),
     new THREE.BufferGeometry(),
   ];
 
-  geometrys[0].setAttribute(
+  geometries[0].setAttribute(
     `position`,
-    new THREE.BufferAttribute(getRandomParticelPos(350 * FACTOR), 3),
+    new THREE.BufferAttribute(getRandomParticlePos(350 * FACTOR), 3),
   );
 
-  geometrys[1].setAttribute(
+  geometries[1].setAttribute(
     `position`,
-    new THREE.BufferAttribute(getRandomParticelPos(1500 * FACTOR), 3),
+    new THREE.BufferAttribute(getRandomParticlePos(1500 * FACTOR), 3),
   );
 
   const loader = new THREE.TextureLoader();
@@ -107,8 +107,8 @@ function installSky(canvas: HTMLCanvasElement) {
   const container = new THREE.Object3D();
   scene.add(container);
 
-  const starsT1 = new THREE.Points(geometrys[0], materials[0]);
-  const starsT2 = new THREE.Points(geometrys[1], materials[1]);
+  const starsT1 = new THREE.Points(geometries[0], materials[0]);
+  const starsT2 = new THREE.Points(geometries[1], materials[1]);
   container.add(starsT1);
   container.add(starsT2);