diff --git a/.github/.kodiak.toml b/.github/.kodiak.toml
index 191f7965bccfc..2b2959eaee4a8 100644
--- a/.github/.kodiak.toml
+++ b/.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]
diff --git a/buildcontainer/README.md b/buildcontainer/README.md
index 1c8371bcda524..1c68d591e1937 100644
--- a/buildcontainer/README.md
+++ b/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
diff --git a/docs/repo-docs/core-concepts/internal-packages.mdx b/docs/repo-docs/core-concepts/internal-packages.mdx
index 1387bf104cd6e..95835e6a2edbd 100644
--- a/docs/repo-docs/core-concepts/internal-packages.mdx
+++ b/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
diff --git a/docs/repo-docs/crafting-your-repository/structuring-a-repository.mdx b/docs/repo-docs/crafting-your-repository/structuring-a-repository.mdx
index 798b4f3ed2fd6..bbc03d3081783 100644
--- a/docs/repo-docs/crafting-your-repository/structuring-a-repository.mdx
+++ b/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).
-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).
diff --git a/docs/repo-docs/guides/generating-code.mdx b/docs/repo-docs/guides/generating-code.mdx
index b3beda6cc28bc..7cb68a5238ea0 100644
--- a/docs/repo-docs/guides/generating-code.mdx
+++ b/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
@@ -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.
- 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.
diff --git a/docs/repo-docs/guides/tools/typescript.mdx b/docs/repo-docs/guides/tools/typescript.mdx
index 9b99a5753c03c..d0f6257b25763 100644
--- a/docs/repo-docs/guides/tools/typescript.mdx
+++ b/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).
diff --git a/docs/src/github.ts b/docs/src/github.ts
index 15625429745c0..480281a63018c 100644
--- a/docs/src/github.ts
+++ b/docs/src/github.ts
@@ -57,7 +57,7 @@ export async function updateComment(
export async function createComment(comment: string): Promise {
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.");
diff --git a/docs/src/validate-docs-links.ts b/docs/src/validate-docs-links.ts
index 0ebcc5f05188d..788fe32c54961 100644
--- a/docs/src/validate-docs-links.ts
+++ b/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;
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 {
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);
diff --git a/packages/create-turbo/__tests__/index.test.ts b/packages/create-turbo/__tests__/index.test.ts
index 369e2eec7d928..eb54a78b2541c 100644
--- a/packages/create-turbo/__tests__/index.test.ts
+++ b/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,
diff --git a/packages/create-turbo/src/commands/create/index.ts b/packages/create-turbo/src/commands/create/index.ts
index 9d21ad65f9120..592cd21d00968 100644
--- a/packages/create-turbo/src/commands/create/index.ts
+++ b/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);
}
diff --git a/packages/top-issues/README.md b/packages/top-issues/README.md
index 4b1cae35996c5..e7bab28c621ca 100644
--- a/packages/top-issues/README.md
+++ b/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.
diff --git a/release.md b/release.md
index 29fe367134e54..3c06f28405f0d 100644
--- a/release.md
+++ b/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`
diff --git a/turborepo-tests/integration/tests/run-logging/log-order-github.t b/turborepo-tests/integration/tests/run-logging/log-order-github.t
index 7e07ce8aa8de3..b1987e18165ae 100644
--- a/turborepo-tests/integration/tests/run-logging/log-order-github.t
+++ b/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)