fix casing for product names (#9229)

.github/.kodiak.toml

@@ -17,7 +17,7 @@ notify_on_conflict = false
 # Without this, only branches that are passing CI will get updated.
 # The benefit of this config is that PRs that we want to automerge, but
 # have failed because the test suite is flaky will get stuck, unless someone
-# presses the Update Branch button manually, or re-triggers the Github workflow
+# presses the Update Branch button manually, or re-triggers the GitHub workflow
 # for tests again. This causes delays in getting easy PRs in.
 always = true
 
@@ -28,7 +28,7 @@ always = true
 # (i.e. PRs with the "pr: automerge" label, which is configured above).
 # This label allows PR authors to keep their PR branch up-to-date without
 # opting into Kodiak's automerge feature. This is useful if you want to use
-# Github's AutoMerge feature instead.
+# GitHub's AutoMerge feature instead.
 autoupdate_label = "pr: autoupdate"
 
 [merge.message]

buildcontainer/README.md

@@ -20,7 +20,7 @@ This project is rather cookbook combing various projects into one. Special to [o
 
 ## Docker
 
-Docker images are available on both [Github](https://ghcr.io/goreleaser/goreleaser-cross) and [Docker hub](https://hub.docker.com/r/goreleaser/goreleaser-cross).
+Docker images are available on both [GitHub](https://ghcr.io/goreleaser/goreleaser-cross) and [Docker hub](https://hub.docker.com/r/goreleaser/goreleaser-cross).
 
 Images from version v1.17.4 are multi-arch. Supported host are listed in the table below
 

docs/repo-docs/core-concepts/internal-packages.mdx

@@ -95,7 +95,7 @@ There are a few important things to notice in this `package.json`:
 #### Limitations and tradeoffs
 
 - **Only applicable when consumers do transpiling**: This strategy can only be used when the package is going to be used in tooling that uses a bundler or natively understands TypeScript. The consumer's bundler is responsible for transpiling the TypeScript packages to JavaScript. If your builds or other usages of the package are not able to consume TypeScript, you will need to move to the [Compiled Packages](#compiled-packages) strategy.
-- **No TypeScript `paths`**: A library that is being transpiled by its consumer cannot use the `compilerOptions.paths` configuration because TypeScript assumes that source code is being transpiled in the package where it is written. If you're using Typescript 5.4 or later, we recommend [using Node.js subpath imports](https://devblogs.microsoft.com/typescript/announcing-typescript-5-4/#auto-import-support-for-subpath-imports). To learn how, visit [our TypeScript page](/repo/docs/guides/tools/typescript#use-nodejs-subpath-imports-instead-of-typescript-compiler-paths).
+- **No TypeScript `paths`**: A library that is being transpiled by its consumer cannot use the `compilerOptions.paths` configuration because TypeScript assumes that source code is being transpiled in the package where it is written. If you're using TypeScript 5.4 or later, we recommend [using Node.js subpath imports](https://devblogs.microsoft.com/typescript/announcing-typescript-5-4/#auto-import-support-for-subpath-imports). To learn how, visit [our TypeScript page](/repo/docs/guides/tools/typescript#use-nodejs-subpath-imports-instead-of-typescript-compiler-paths).
 - **Turborepo cannot cache a build for a Just-in-Time Package**: Because the package doesn't have its own `build` step, it can't be cached by Turborepo. This tradeoff may make sense for you if you want to keep configuration to a minimum and are okay with the build times for your applications.
 
 ### Compiled Packages

docs/repo-docs/crafting-your-repository/structuring-a-repository.mdx

@@ -318,7 +318,7 @@ Using exports this way provides three major benefits:
 [The `imports` field](https://nodejs.org/api/packages.html#imports) gives you a way to create subpaths to other modules within your package. You can think of these like "shortcuts" to write simpler import paths that are more resilient to refactors that move files. To learn how, visit [the TypeScript page](/repo/docs/guides/tools/typescript#use-nodejs-subpath-imports-instead-of-typescript-compiler-paths).
 
 <Callout type="info">
-You may be more familiar with TypeScript's `compilerOptions#paths` option, which accomplishes a similar goal. As of Typescript 5.4, TypeScript can infer subpaths from `imports`, making it a better option since you'll be working with Node.js conventions. For more information, visit [our Typescript guide](/repo/docs/guides/tools/typescript#use-nodejs-subpath-imports-instead-of-typescript-compiler-paths).
+You may be more familiar with TypeScript's `compilerOptions#paths` option, which accomplishes a similar goal. As of TypeScript 5.4, TypeScript can infer subpaths from `imports`, making it a better option since you'll be working with Node.js conventions. For more information, visit [our TypeScript guide](/repo/docs/guides/tools/typescript#use-nodejs-subpath-imports-instead-of-typescript-compiler-paths).
 
 </Callout>
 

docs/repo-docs/guides/generating-code.mdx

@@ -63,7 +63,7 @@ generators within a repo configured with Turborepo.
 1. Generators are automatically discovered, loaded, and organized per workspace (no need to manually `load` them within a single configuration file)
 2. Generators are automatically run from the root of the workspace where they are defined
 3. Generators can be invoked from anywhere within your repo (or outside out it via the [`--root`](/repo/docs/reference/generate#--root-path) flag)
-4. Typescript generators are supported with zero configuration
+4. TypeScript generators are supported with zero configuration
 5. `plop` is not required to be installed as a dependency of your repo
 
 <Callout type="info" title="Known issue">
@@ -82,7 +82,7 @@ You'll be prompted to select an existing generator or to create one if you don't
 manually at `turbo/generators/config.ts` (or `config.js`) at the root of your repo - or within _any_ workspace.
 
 <Callout type="info">
-  If you are using Typescript, you will need to install [the `@turbo/gen`
+  If you are using TypeScript, you will need to install [the `@turbo/gen`
   package](https://github.com/vercel/turborepo/tree/main/packages/turbo-gen) as
   a `devDependency` to access the required TS types.
 </Callout>

docs/repo-docs/guides/tools/typescript.mdx

@@ -321,7 +321,7 @@ We don't recommend using TypeScript Project References as they introduce both an
 
 ### Your editor won't use a package's TypeScript version
 
-`tsserver` is not able to use different Typescript versions for different packages in your code editor. Instead, it will discover a specific version and use that everywhere.
+`tsserver` is not able to use different TypeScript versions for different packages in your code editor. Instead, it will discover a specific version and use that everywhere.
 
 This can result in differences between the linting errors that show in your editor and when you run `tsc` scripts to check types. If this is an issue for you, consider [keeping the TypeScript dependency on the same version](/repo/docs/crafting-your-repository/managing-dependencies#keeping-dependencies-on-the-same-version).
 

docs/src/github.ts

@@ -57,7 +57,7 @@ export async function updateComment(
 export async function createComment(comment: string): Promise<string> {
   if (isFork) {
     setFailed(
-      "The action could not create a Github comment because it is initiated from a forked repo. View the action logs for a list of broken links."
+      "The action could not create a GitHub comment because it is initiated from a forked repo. View the action logs for a list of broken links."
     );
 
     return "";
@@ -111,7 +111,7 @@ export async function updateCheckStatus(
   if (isFork) {
     if (errorsExist) {
       setFailed(
-        "This PR introduces broken links to the docs. The action could not create a Github check because it is initiated from a forked repo."
+        "This PR introduces broken links to the docs. The action could not create a GitHub check because it is initiated from a forked repo."
       );
     } else {
       console.log("Link validation was successful.");

docs/src/validate-docs-links.ts

@@ -5,7 +5,7 @@ import markdown from "remark-parse";
 import remarkToRehype from "remark-rehype";
 import raw from "rehype-raw";
 import visit from "unist-util-visit";
-import GithubSlugger from "github-slugger";
+import GitHubSlugger from "github-slugger";
 import matter from "gray-matter";
 import {
   COMMENT_TAG,
@@ -57,7 +57,7 @@ type ErrorType = Exclude<keyof Errors, "doc">;
 const DOCS_PATH = ".";
 const EXCLUDED_HASHES = ["top"];
 
-const slugger = new GithubSlugger();
+const slugger = new GitHubSlugger();
 
 // Collect the paths of all .mdx files in the passed directories
 async function getAllMdxFilePaths(
@@ -323,7 +323,7 @@ async function validateAllInternalLinks(): Promise<void> {
     try {
       await updateCheckStatus(errorsExist, commentUrl);
     } catch (error) {
-      setFailed("Failed to create Github check: " + error);
+      setFailed("Failed to create GitHub check: " + error);
     }
   } catch (error) {
     setFailed("Error validating internal links: " + error);

packages/create-turbo/__tests__/index.test.ts

@@ -248,7 +248,7 @@ describe("create-turbo", () => {
     expect(mockConsole.error).toHaveBeenNthCalledWith(
       1,
       logger.turboRed(bold(">>>")),
-      red("Unable to download template from Github")
+      red("Unable to download template from GitHub")
     );
     expect(mockConsole.error).toHaveBeenNthCalledWith(
       2,

packages/create-turbo/src/commands/create/index.ts

@@ -49,7 +49,7 @@ function handleErrors(
     process.exit(1);
     // handle download errors from @turbo/utils
   } else if (err instanceof DownloadError) {
-    error(red("Unable to download template from Github"));
+    error(red("Unable to download template from GitHub"));
     error(red(err.message));
     process.exit(1);
   }

packages/top-issues/README.md

@@ -1,8 +1,8 @@
 # `@turbo/top-issues`
 
-This is an internal package that is used by a Github Actions Workflow to post
+This is an internal package that is used by a GitHub Actions Workflow to post
 top issues in `vercel/turbo` to Slack.
 
-The code here gets the top issues and writes them to a file. The Github Action
+The code here gets the top issues and writes them to a file. The GitHub Action
 workflow will then take that file and post it to Slack with a marketplace
 action.

release.md

@@ -57,7 +57,7 @@ You need to run `git push --follow-tags` to finish the release.
 
 ### Notes
 
-- Github Release Notes are published automatically using the config from [`turborepo-release.yml`][2],
+- GitHub Release Notes are published automatically using the config from [`turborepo-release.yml`][2],
   triggered by the [`turbo-orchestrator`][3] bot.
 
 ## Release `@turbo/repository`

turborepo-tests/integration/tests/run-logging/log-order-github.t

@@ -1,7 +1,7 @@
 # Setup
   $ . ${TESTDIR}/../../../helpers/setup_integration_test.sh ordered
 
-# Build as if we are in Github Actions
+# Build as if we are in GitHub Actions
 Note that we need to use (re) for lines that start with '> '
 because otherwise prysk interprets them as multiline commands
   $ GITHUB_ACTIONS=1 ${TURBO} run build --force
@@ -31,7 +31,7 @@ because otherwise prysk interprets them as multiline commands
   Cached:    0 cached, 2 total
     Time:\s*[\.0-9]+m?s  (re)
 
-# Build as if we are in Github Actions with a task log prefix.
+# Build as if we are in GitHub Actions with a task log prefix.
   $ GITHUB_ACTIONS=1 ${TURBO} run build --force --log-prefix="task" --filter=util
   \xe2\x80\xa2 Packages in scope: util (esc)
   \xe2\x80\xa2 Running build in 1 packages (esc)