Repo sync

.github/instructions/code.instructions.md

@@ -15,7 +15,7 @@ For code reviews, follow guidelines, tests, and validate instructions. For creat
 - Be careful fetching full HTML pages off the internet. Prefer to use gh cli whenever possible for github.com. Limit the number of tokens when grabbing HTML.
 - Avoid pull requests with over 300 lines of code changed. When significantly larger, offer to split up into smaller pull requests if possible.
 - All new code should be written in TypeScript and not JavaScript.
-- We use absolute imports, relative to the `src` directory, using the `@` symbol. For example, `getRedirect` which lives in `src/redirects/lib/get-redirect.js` can be imported with `import getRedirect from '@/redirects/lib/get-redirect'`. The same rule applies for TypeScript (`.ts`) imports, e.g. `import type { GeneralSearchHit } from '@/search/types'`
+- We use absolute imports, relative to the `src` directory, using the `@` symbol. For example, `getRedirect` which lives in `src/redirects/lib/get-redirect.ts` can be imported with `import getRedirect from '@/redirects/lib/get-redirect'`. The same rule applies for TypeScript (`.ts`) imports, e.g. `import type { GeneralSearchHit } from '@/search/types'`
 
 ## Tests
 

.github/instructions/content.instructions.md

@@ -14,7 +14,7 @@ Before committing content changes, always:
 1. **Use the content linter** to validate content: `npm run lint-content -- --paths <file-paths>`
 2. **Check for proper variable usage** in your content
 3. **Verify [AUTOTITLE] links** point to existing articles
-4. **Run tests** on changed content: `npm run test -- src/content-render/tests/render-changed-and-deleted-files.js`
+4. **Run tests** on changed content: `npm run test -- src/content-render/tests/render-changed-and-deleted-files.ts`
 
 ## Bullet lists
 

.github/workflows/codeql.yml

@@ -9,9 +9,7 @@ on:
     branches:
       - main
     paths:
-      - '**/*.js'
       - '**/*.ts'
-      - '**/*.jsx'
       - '**/*.tsx'
       - '.github/workflows/codeql.yml'
   # This is so that when CodeQL runs on a pull request, it can compare

.github/workflows/count-translation-corruptions.yml

@@ -9,7 +9,7 @@ on:
   pull_request:
     paths:
       - src/languages/scripts/count-translation-corruptions.ts
-      - src/languages/lib/correct-translation-content.js
+      - src/languages/lib/correct-translation-content.ts
       - .github/workflows/count-translation-corruptions.yml
       - .github/actions/node-npm-setup/action.yml
       - .github/actions/clone-translations/action.yml

.github/workflows/enterprise-dates.yml

@@ -28,7 +28,7 @@ jobs:
 
       - uses: ./.github/actions/node-npm-setup
 
-      - name: Run src/ghes-releases/scripts/update-enterprise-dates.js
+      - name: Run src/ghes-releases/scripts/update-enterprise-dates.ts
         run: npm run update-enterprise-dates
         env:
           GITHUB_TOKEN: ${{ secrets.DOCS_BOT_PAT_BASE }}
@@ -42,7 +42,7 @@ jobs:
         with:
           # need to use a token with repo and workflow scopes for this step
           token: ${{ secrets.DOCS_BOT_PAT_BASE }}
-          commit-message: '🤖 ran src/ghes-releases/scripts/update-enterprise-dates.js'
+          commit-message: '🤖 ran src/ghes-releases/scripts/update-enterprise-dates.ts'
           title: 🤖 src/ghes-releases/lib/enterprise-dates.json update
           body:
             "Hello! The GitHub Enterprise Server release dates have changed.\n\n

.github/workflows/move-content.yml

@@ -7,7 +7,7 @@ name: Move content script test
 on:
   pull_request:
     paths:
-      - src/content-render/scripts/move-content.js
+      - src/content-render/scripts/move-content.ts
       - src/content-render/scripts/test-move-content.ts
       - 'src/frame/lib/**/*.js'
       - .github/workflows/move-content.yml

.github/workflows/orphaned-files-check.yml

@@ -14,10 +14,10 @@ on:
       - .github/workflows/orphaned-files-check.yml
       # In case any of the dependencies affect the script
       - 'package*.json'
-      - src/assets/scripts/find-orphaned-assets.js
+      - src/assets/scripts/find-orphaned-assets.ts
       - src/content-render/scripts/reusables-cli/find/unused.ts
       - src/workflows/walk-files.ts
-      - src/languages/lib/languages.js
+      - src/languages/lib/languages.ts
       - .github/actions/clone-translations/action.yml
       - .github/actions/node-npm-setup/action.yml
 

.github/workflows/reviewers-docs-engineering.yml

@@ -15,7 +15,6 @@ on:
       - reopened
       - synchronize
     paths:
-      - '**.js'
       - '**.ts'
       - '**.tsx'
       - '**.scss'

Dockerfile

@@ -152,6 +152,4 @@ ARG BUILD_SHA
 ENV BUILD_SHA=$BUILD_SHA
 
 # Entrypoint to start the server
-# Note: Currently we have to use tsx because
-# we have a mix of `.ts` and `.js` files with multiple import patterns
 CMD ["node_modules/.bin/tsx", "src/frame/server.ts"]

Dockerfile.openapi_decorator

@@ -16,4 +16,4 @@ ADD --chown=node:node data /openapi-check/data
 
 RUN npm ci -D
 
-ENTRYPOINT ["node", "/openapi-check/src/rest/scripts/openapi-check.js"]
+ENTRYPOINT ["node", "/openapi-check/src/rest/scripts/openapi-check.ts"]

content/README.md

@@ -51,13 +51,13 @@ It is a block of key-value content that lives at the top of every Markdown file.
 
 The following frontmatter values have special meanings and requirements for this site.
 There's also a schema that's used by the test suite to validate every page's frontmatter.
-See [`lib/frontmatter.js`](/src/frame/lib/frontmatter.js).
+See [`lib/frontmatter.ts`](/src/frame/lib/frontmatter.ts).
 
 ### `versions`
 
-- Purpose: Indicates the [versions](/src/versions/lib/all-versions.js) to which a page applies.
+- Purpose: Indicates the [versions](/src/versions/lib/all-versions.ts) to which a page applies.
 See [Versioning](#versioning) for more info.
-- Type: `Object`. Allowable keys map to product names and can be found in the `versions` object in [`lib/frontmatter.js`](/src/frame/lib/frontmatter.js).
+- Type: `Object`. Allowable keys map to product names and can be found in the `versions` object in [`lib/frontmatter.ts`](/src/frame/lib/frontmatter.ts).
 - This frontmatter value is currently **required** for all pages.
 - The `*` is used to denote all releases for the version.
 
@@ -197,7 +197,7 @@ featuredLinks:
 
 ### `allowTitleToDifferFromFilename`
 
-- Purpose: Indicates whether a page is allowed to have a title that differs from its filename. Pages with this frontmatter set to `true` will not be flagged in tests or updated by `src/content-render/scripts/reconcile-filenames-with-ids.js`. Use this value if a file's `title` frontmatter includes Liquid or punctuation that cannot be part of the filename. For example, the article [About Enterprise Managed Users](https://docs.github.com/en/enterprise-cloud@latest/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/about-enterprise-managed-users) uses a Liquid reusable in its title, `'About {% data variables.product.prodname_emus %}'`, which cannot be in the filename, `about-enterprise-managed-users.md`, so the `allowTitleToDifferFromFilename` frontmatter is set to `true`.
+- Purpose: Indicates whether a page is allowed to have a title that differs from its filename. Pages with this frontmatter set to `true` will not be flagged in tests or updated by `src/content-render/scripts/reconcile-filenames-with-ids.ts`. Use this value if a file's `title` frontmatter includes Liquid or punctuation that cannot be part of the filename. For example, the article [About Enterprise Managed Users](https://docs.github.com/en/enterprise-cloud@latest/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/about-enterprise-managed-users) uses a Liquid reusable in its title, `'About {% data variables.product.prodname_emus %}'`, which cannot be in the filename, `about-enterprise-managed-users.md`, so the `allowTitleToDifferFromFilename` frontmatter is set to `true`.
 - Type: `Boolean`. Default is `false`.
 - Optional.
 
@@ -327,7 +327,7 @@ A content file can have **two** types of versioning:
 - Liquid statements in content (**optional**)
     - Conditionally render content depending on the current version being viewed. See [Versioning documentation](https://docs.github.com/en/contributing/writing-for-github-docs/versioning-documentation#versioning-with-liquid-conditional-operators) for more info. Note Liquid conditionals can also appear in `data` and `include` files.
 
-**Note**: As of early 2021, the `free-pro-team@latest` version is not included URLs. A helper function called `src/versions/lib/remove-fpt-from-path.js` removes the version from URLs.
+**Note**: As of early 2021, the `free-pro-team@latest` version is not included URLs. A helper function called `src/versions/lib/remove-fpt-from-path.ts` removes the version from URLs.
 
 ## Filenames
 

content/contributing/setting-up-your-environment-to-work-on-github-docs/troubleshooting-your-environment.md

@@ -9,7 +9,7 @@ versions:
 
 ## Troubleshooting tests that fail locally but pass in CI
 
-If you run tests locally and get failures in `tests/rendering/server.js` around static assets, stylesheets, or the client-side JavaScript bundle, but the same tests pass in CI on a PR, run the command `npm run build`. This is a one-time command that creates static assets locally.
+If you run tests locally and get failures in `tests/rendering/server.ts` around static assets, stylesheets, or the client-side JavaScript bundle, but the same tests pass in CI on a PR, run the command `npm run build`. This is a one-time command that creates static assets locally.
 
 For more information, see [AUTOTITLE](/contributing/setting-up-your-environment-to-work-on-github-docs/creating-a-local-environment).
 

content/contributing/writing-for-github-docs/using-markdown-and-liquid-in-github-docs.md

@@ -469,7 +469,7 @@ For more information about links, see [AUTOTITLE](/contributing/style-guide-and-
 Because the site is dynamic, it does not build HTML files for each different version of an article. Instead it generates a "permalink" for every version of the article. It does this based on the article's [`versions` frontmatter](/contributing/syntax-and-versioning-for-github-docs/using-yaml-frontmatter#versions).
 
 > [!NOTE]
-> As of early 2021, the `free-pro-team@latest` version is not included in URLs. A helper function called `lib/remove-fpt-from-path.js` removes the version from URLs.
+> As of early 2021, the `free-pro-team@latest` version is not included in URLs. A helper function called `lib/remove-fpt-from-path.ts` removes the version from URLs.
 
 For example, an article that is available in currently supported versions will have permalink URLs like the following:
 

content/contributing/writing-for-github-docs/using-yaml-frontmatter.md

@@ -19,7 +19,7 @@ It is a block of key-value content that lives at the top of every Markdown file
 
 The following frontmatter values have special meanings and requirements for {% data variables.product.prodname_docs %}.
 There's also a schema that's used by the test suite to validate every page's frontmatter.
-For more information, see [`lib/frontmatter.js`](https://github.com/github/docs/blob/main/src/frame/lib/frontmatter.js).
+For more information, see [`lib/frontmatter.ts`](https://github.com/github/docs/blob/main/src/frame/lib/frontmatter.ts).
 
 * [`versions`](#versions)
 * [`redirect_from`](#redirect_from)
@@ -49,7 +49,7 @@ For more information, see [`lib/frontmatter.js`](https://github.com/github/docs/
 
 * Purpose: Indicates the [versions](https://github.com/github/docs/blob/main/src/versions/lib/all-versions.ts) to which a page applies.
 For more information about the different types of versioning, see [Versioning documentation](/contributing/syntax-and-versioning-for-github-docs/versioning-documentation).
-* Type: `Object`. Allowable keys map to product names and can be found in the `versions` object in [`lib/frontmatter.js`](https://github.com/github/docs/blob/main/src/frame/lib/frontmatter.js).
+* Type: `Object`. Allowable keys map to product names and can be found in the `versions` object in [`lib/frontmatter.ts`](https://github.com/github/docs/blob/main/src/frame/lib/frontmatter.ts).
 * This frontmatter value is currently **required** for all pages.
 * The `*` is used to denote all releases for the version.
 * Must be present for all `index.md` files, but actual value is computed at runtime based on the children.
@@ -191,7 +191,7 @@ featuredLinks:
 
 ### `allowTitleToDifferFromFilename`
 
-* Purpose: Indicates whether a page is allowed to have a title that differs from its filename. For example, `content/rest/reference/orgs.md` has a title of `Organizations` instead of `Orgs`. Pages with this frontmatter set to `true` will not be flagged in tests or updated by `src/content-render/scripts/reconcile-filenames-with-ids.js`.
+* Purpose: Indicates whether a page is allowed to have a title that differs from its filename. For example, `content/rest/reference/orgs.md` has a title of `Organizations` instead of `Orgs`. Pages with this frontmatter set to `true` will not be flagged in tests or updated by `src/content-render/scripts/reconcile-filenames-with-ids.ts`.
 * Type: `Boolean`. Default is `false`.
 * Optional.
 

content/contributing/writing-for-github-docs/versioning-documentation.md

@@ -68,7 +68,7 @@ For {% data variables.product.prodname_ghe_cloud %}, use `enterprise-cloud@lates
 
 ### {% data variables.product.prodname_ghe_server %}
 
-Documentation for {% data variables.product.prodname_ghe_server %} has multiple versions and can be divided into two types: documentation for _supported releases_ (we support four at any one time), and documentation for _{% data variables.release-phases.closing_down %} releases_ (we do not link to these on the Docs site but we support a "frozen" snapshot of these docs in perpetuity, so they can still be accessed if you know the URLs). See [`lib/enterprise-server-releases.js`](https://github.com/github/docs/blob/main/src/versions/lib/enterprise-server-releases.js) for a list.
+Documentation for {% data variables.product.prodname_ghe_server %} has multiple versions and can be divided into two types: documentation for _supported releases_ (we support four at any one time), and documentation for _{% data variables.release-phases.closing_down %} releases_ (we do not link to these on the Docs site but we support a "frozen" snapshot of these docs in perpetuity, so they can still be accessed if you know the URLs). See [`lib/enterprise-server-releases.ts`](https://github.com/github/docs/blob/main/src/versions/lib/enterprise-server-releases.ts) for a list.
 
 The versions are named `enterprise-server@<release>`. The short name is `ghes`. In Liquid conditionals, we can specify ranges, like `ghes > 3.0`. For more information, see [Versioning with Liquid conditional operators](#versioning-with-liquid-conditional-operators).
 

contributing/development.md

@@ -42,7 +42,7 @@ In a matter of minutes, you will be ready to edit, review and test your changes
 
 By default the local server won't run with all supported languages enabled. If you need to run the server with a particular language, you can temporarily edit the `start` script in `package.json` and update the `ENABLED_LANGUAGES` variable. For example, to enable Japanese and Portuguese, you can set it to `ENABLED_LANGUAGES='en,ja,pt'` and then you need to restart the server for the change to take effect.
 
-The supported language codes are defined in [lib/languages.js](../src/languages/lib/languages.js).
+The supported language codes are defined in [lib/languages.ts](../src/languages/lib/languages.ts).
 
 ## Site structure
 

data/features/README.md

@@ -39,7 +39,7 @@ You cannot use `feature:` to specify multiple concurrent versions, as this is no
 
 ## Schema enforcement
 
-The schema for validating the feature versioning lives in [`src/data-directory/lib/data-schemas/features.js`](../../src/data-directory/lib/data-schemas/features.js).
+The schema for validating the feature versioning lives in [`src/data-directory/lib/data-schemas/features.ts`](../../src/data-directory/lib/data-schemas/features.ts).
 
 ## Script to remove feature tags
 

data/learning-tracks/README.md

@@ -25,7 +25,7 @@ Learning track data for a product is defined in two places:
 
 ## Versioning
 
-Versioning for learning tracks is processed at page render time. The code lives in [`lib/learning-tracks.js`](lib/learning-tracks.js), which is called by `page.render()`. The processed learning tracks are then rendered by `components/guides`.
+Versioning for learning tracks is processed at page render time. The code lives in [`lib/learning-tracks.ts`](lib/learning-tracks.ts), which is called by `page.render()`. The processed learning tracks are then rendered by `components/guides`.
 
 Liquid conditionals do **not** have to be used for versioning in the YAML file for guides. Only the learning track guides that apply to the current version will be rendered automatically. If there aren't any tracks with guides that belong to the current version, the learning tracks section will not render at all.
 
@@ -48,4 +48,4 @@ If the `versions` property is not included, it's assumed the track is available
 
 ## Schema enforcement
 
-The schema for validating the learning track YAML lives in [`src/content-linter/lib/learning-tracks-schema.js`](src/content-linter/lib/learning-tracks-schema.js) and is exercised by [`tests/content/lint-files.js`](tests/content/lint-files.js).
+The schema for validating the learning track YAML lives in [`src/content-linter/lib/learning-tracks-schema.ts`](src/content-linter/lib/learning-tracks-schema.ts) and is exercised by [`tests/content/lint-files.ts`](tests/content/lint-files.ts).

data/product-examples/README.md

@@ -35,7 +35,7 @@ where the syntax for `versions` is the same as the [frontmatter `versions` prope
 
 ## Rendering
 
-The product example data is added to the `context` object in `src/frame/middleware/context/product-examples.js`.
+The product example data is added to the `context` object in `src/frame/middleware/context/product-examples.ts`.
 
 The data is then rendered by `components/landing`.
 

data/release-notes/enterprise-server/README.md

@@ -25,7 +25,7 @@ The directories are named by GHES release number (with a hyphen instead of a per
 
 The YAML files in each directory are named by patch number. Some patch filenames may end with `-rc<num>.yml`, which means it's a release candidate. A release candidate file also requires `release_candidate: true` in the YAML data.
 
-Release notes of deprecated GHES versions (see `lib/enterprise-server-releases.js`) are **not** removed from the site and will always be displayed alongside currently supported versions.
+Release notes of deprecated GHES versions (see `lib/enterprise-server-releases.ts`) are **not** removed from the site and will always be displayed alongside currently supported versions.
 
 Note that patch files can be deprecated individually (i.e., hidden on the docs site) by an optional `deprecated: true` property.
 
@@ -41,6 +41,6 @@ The release notes page has a custom design with CSS in `stylesheets/release-note
 
 ### Schema
 
-The schema that validates the YAML data lives in `src/content-linter/lib/release-notes-schema.js`. See the schema file to find out the required and optional properties.
+The schema that validates the YAML data lives in `src/content-linter/lib/release-notes-schema.ts`. See the schema file to find out the required and optional properties.
 
-The schema is exercised by a test in `src/content-linter/tests/lint-files.js`. The test will fail if the data does not pass validation.
+The schema is exercised by a test in `src/content-linter/tests/lint-files.ts`. The test will fail if the data does not pass validation.

data/tables/README.md

@@ -86,7 +86,7 @@ After creating all three files:
 
 1. **Build the site**: Run `npm run build`
 2. **Test schemas**: Run `npm test -- src/data-directory/tests`
-3. **Fix any errors**: If you get failures in `src/data-directory/tests/data-schemas.js`:
+3. **Fix any errors**: If you get failures in `src/data-directory/tests/data-schemas.ts`:
    - Copy the error message
    - In VS Code Copilot Chat, type: "When I ran the schema test, I got this error:" and paste the error
    - Update your schema file based on Copilot's suggestions
@@ -96,4 +96,4 @@ After creating all three files:
 
 Once your table is working and tests pass, create a pull request for review.
 
-The `docs-engineering` team must review and approve your implementation.
+The `docs-engineering` team must review and approve your implementation.