fix: rename next to remix

Author: jacobparis

Diff for: .github/workflows/nightly.yml

@@ -24,7 +24,7 @@ jobs:
     runs-on: ubuntu-latest
     outputs:
       # allows this to be used in the `comment` job below - will be undefined if there's no release necessary
-      NEXT_VERSION: ${{ steps.version.outputs.NEXT_VERSION }}
+      REMIX_VERSION: ${{ steps.version.outputs.REMIX_VERSION }}
     steps:
       - name: ⬇️ Checkout repo
         uses: actions/checkout@v4
@@ -63,44 +63,44 @@ jobs:
             # yyyyMMdd format (e.g. 20221207)
             DATE=$(date '+%Y%m%d')
             # v0.0.0-nightly-<short sha>-<date>
-            NEXT_VERSION=0.0.0-nightly-${SHORT_SHA}-${DATE}
+            REMIX_VERSION=0.0.0-nightly-${SHORT_SHA}-${DATE}
             # set output so it can be used in other jobs
-            echo "NEXT_VERSION=${NEXT_VERSION}" >> $GITHUB_OUTPUT
+            echo "REMIX_VERSION=${REMIX_VERSION}" >> $GITHUB_OUTPUT
           fi
 
       - name: ⤴️ Update version
-        if: steps.version.outputs.NEXT_VERSION
+        if: steps.version.outputs.REMIX_VERSION
         run: |
           git config --local user.email "[email protected]"
           git config --local user.name "Remix Run Bot"
-          git checkout -b nightly/${{ steps.version.outputs.NEXT_VERSION }}
-          pnpm run version ${{steps.version.outputs.NEXT_VERSION}} --skip-prompt
+          git checkout -b nightly/${{ steps.version.outputs.REMIX_VERSION }}
+          pnpm run version ${{steps.version.outputs.REMIX_VERSION}} --skip-prompt
           git push origin --tags
 
       - name: 🏗 Build
-        if: steps.version.outputs.NEXT_VERSION
+        if: steps.version.outputs.REMIX_VERSION
         run: pnpm build
 
       - name: 🔐 Setup npm auth
-        if: steps.version.outputs.NEXT_VERSION
+        if: steps.version.outputs.REMIX_VERSION
         run: |
           echo "registry=https://registry.npmjs.org" >> ~/.npmrc
           echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" >> ~/.npmrc
 
       - name: 🚀 Publish
-        if: steps.version.outputs.NEXT_VERSION
+        if: steps.version.outputs.REMIX_VERSION
         run: npm run publish
 
   comment:
     needs: [nightly]
     name: 📝 Comment on related issues and pull requests
-    if: github.repository == 'remix-run/remix' && needs.nightly.outputs.NEXT_VERSION
+    if: github.repository == 'remix-run/remix' && needs.nightly.outputs.REMIX_VERSION
     uses: ./.github/workflows/release-comments.yml
 
   deployments:
     needs: [nightly]
     name: 🚀 Deployment Tests
-    if: github.repository == 'remix-run/remix' && needs.nightly.outputs.NEXT_VERSION
+    if: github.repository == 'remix-run/remix' && needs.nightly.outputs.REMIX_VERSION
     uses: remix-run/remix/.github/workflows/deployments.yml@main
     secrets:
       TEST_AWS_ACCESS_KEY_ID: ${{ secrets.TEST_AWS_ACCESS_KEY_ID }}
@@ -116,7 +116,7 @@ jobs:
   stacks:
     needs: [nightly]
     name: 🥞 Remix Stacks Test
-    if: github.repository == 'remix-run/remix' && needs.nightly.outputs.NEXT_VERSION
+    if: github.repository == 'remix-run/remix' && needs.nightly.outputs.REMIX_VERSION
     uses: remix-run/remix/.github/workflows/stacks.yml@main
     with:
-      version: "${{ needs.nightly.outputs.NEXT_VERSION }}"
+      version: "${{ needs.nightly.outputs.REMIX_VERSION }}"

Diff for: .github/workflows/release-experimental.yml

@@ -42,9 +42,9 @@ jobs:
           git config --local user.email "[email protected]"
           git config --local user.name "Remix Run Bot"
           SHORT_SHA=$(git rev-parse --short HEAD)
-          NEXT_VERSION=0.0.0-experimental-${SHORT_SHA}
-          git checkout -b experimental/${NEXT_VERSION}
-          pnpm run version ${NEXT_VERSION} --skip-prompt
+          REMIX_VERSION=0.0.0-experimental-${SHORT_SHA}
+          git checkout -b experimental/${REMIX_VERSION}
+          pnpm run version ${REMIX_VERSION} --skip-prompt
           git push origin --tags
 
       - name: 🏗 Build

Diff for: CHANGELOG.md

@@ -263,7 +263,7 @@ We found that the `future.unstable_fogOfWar` flag name could be a bit confusing
 
 The original Single Fetch approach was based on an assumption that an eventual `middleware` implementation would require something like the `ResponseStub` API so users could mutate `status`/`headers` in `middleware` before/after handlers as well as during handlers. As part of Single Fetch, we wanted to align how response headers would be merged between document and data requests. Thinking `response` was the future API, we aligned document requests to use the `response` stub that data requests were using, and we stopped using the `headers()` function.
 
-However, the realization/alignment between Michael and Ryan on the recent [roadmap planning](https://www.youtube.com/watch?v=f5z_axCofW0) made us realize that the original assumption was incorrect. `middleware` won't need a `response` stub - as users can just mutate the `Response` they get from `await next()` directly.
+However, the realization/alignment between Michael and Ryan on the recent [roadmap planning](https://www.youtube.com/watch?v=f5z_axCofW0) made us realize that the original assumption was incorrect. `middleware` won't need a `response` stub - as users can just mutate the `Response` they get from `await remix()` directly.
 
 Removing that assumption, and still wanting to align how headers get merged between document and data requests, it makes more sense to stick with the current `headers()` API and align Single Fetch data requests to use that existing API. This was we don't need to introduce any new header-related APIs which will make the adoption of Single Fetch much easier.
 
@@ -275,7 +275,7 @@ With this change:
   - ✅ `return { data: "whatever" };`
 - If you _were_ returning a custom `status` or `headers` via `json`/`defer`:
   - We've added a new API-compatible [`unstable_data`](https://remix.run/docs/utils/data) utility that will let you send back `status`/`headers` alongside your raw data without having to encode it into a `Response`
-- We will be removing both `json` and `defer` in the next major version, but both _should_ still work in Single Fetch in v2 to allow for incremental adoption of the new behavior
+- We will be removing both `json` and `defer` in the remix major version, but both _should_ still work in Single Fetch in v2 to allow for incremental adoption of the new behavior
 
 ⚠️ If you've already adopted Single Fetch in it's unstable state and converted to `response` stub, you'll need to move those changes back to leveraging the `headers()` API.
 

Diff for: DEVELOPMENT.md

@@ -43,7 +43,7 @@ New releases should be created from release branches originating from the `dev`
 - If needed, bump the dependencies to the correct React Router release
   - `./scripts/bump-router-versions.sh [pre|latest]`
 - Create a new release branch with the `release-` prefix
-  - `git checkout -b release-next`
+  - `git checkout -b release-remix`
   - **IMPORTANT:** The `release-` prefix is important, as this is what triggers our GitHub CI workflow that will ultimately publish the release
 - Merge `main` into the release branch
 
@@ -93,9 +93,9 @@ You may need to make changes to a pre-release prior to publishing a final stable
 - Once the release is published:
   - Pull the latest `release-*` branch containing the PR you just merged
   - Merge the `release-*` branch into `main` **using a non-fast-forward merge** and push it up to GitHub
-    - `git checkout main; git merge --no-ff release-next`
+    - `git checkout main; git merge --no-ff release-remix`
   - Merge the `release-*` branch into `dev` **using a non-fast-forward merge** and push it up to GitHub
-    - `git checkout dev; git merge --no-ff release-next`
+    - `git checkout dev; git merge --no-ff release-remix`
   - Convert the `[email protected]` tag to a Release on GitHub with the name `v2.x.y` and add a deep-link to the release heading in `CHANGELOG.md`
 
 ### Hotfix releases

Diff for: decisions/0005-remixing-react-router.md

@@ -30,7 +30,7 @@ In [Remixing React Router][remixing router], Ryan gives an overview of the work
 
 ### Move the bulk of logic to a framework-agnostic router
 
-Thankfully this decision was sort of already made by Ryan. Maybe a surprise to some, maybe not, the current transition manager doesn't import or reference `react` or `react-router` a single time. This is by design because the logic being handled has nothing to do with how to render the UI layer. It's all about "what route am I on?", "what route am I going to?", "how do I load data for the next route?", "how do I interrupt ongoing navigations?" etc. None of these decisions actually _care_ about how the route and its data will eventually be rendered. Instead, the router simply needs to know whether given routes _have_ components and/or error boundaries - but it doesn't need to know about them or how to render them.
+Thankfully this decision was sort of already made by Ryan. Maybe a surprise to some, maybe not, the current transition manager doesn't import or reference `react` or `react-router` a single time. This is by design because the logic being handled has nothing to do with how to render the UI layer. It's all about "what route am I on?", "what route am I going to?", "how do I load data for the remix route?", "how do I interrupt ongoing navigations?" etc. None of these decisions actually _care_ about how the route and its data will eventually be rendered. Instead, the router simply needs to know whether given routes _have_ components and/or error boundaries - but it doesn't need to know about them or how to render them.
 
 This is a huge advantage since it's a strict requirement in order to eventually support UI libraries other than React (namely Preact and Vue). So in the end, we have a `@remix-run/router` package with _zero_ dependencies 🔥.
 
@@ -82,7 +82,7 @@ We plan to export `useNavigation` in Remix and encourage folks to switch, but we
 In Remix, the `useTransition` hook returned a Transition object which had a `state` property of `"idle" | "loading" | "submitting"`. It also had a `type` property which represented sort of "sub-states" such as `"normalLoad" | "actionReload" | "loaderRedirect"` etc. In React Router we chose to get rid of the `type` field for 2 reasons:
 
 1. In practice, we found that the _vast_ majority of the time all you needed to reference was the `state`
-2. For scenarios in which you really do need to distinguish, we are pretty sure that in all cases, you can deduce the `type` from `state`, current location (`useLocation`), next location (`useNavigation().location`), and submission info (`useNavigation().formData`).
+2. For scenarios in which you really do need to distinguish, we are pretty sure that in all cases, you can deduce the `type` from `state`, current location (`useLocation`), remix location (`useNavigation().location`), and submission info (`useNavigation().formData`).
 
 **`useTransition().submission` is flattened**
 

Diff for: decisions/0006-linear-workflow.md

@@ -17,7 +17,7 @@ This document will use many of the following Linear terms:
 - **Project** - A group of issues that comprise a larger scope of work (for example, a new feature)
   - Projects will almost always span multiple Cycles.
 - **Status** - The state of a given Issue (Todo, In Progress, Done, etc.)
-- **Assignee** - The person the Issue is currently assigned to - this indicates who is expected to take the next action to move the Issue forward
+- **Assignee** - The person the Issue is currently assigned to - this indicates who is expected to take the remix action to move the Issue forward
 - **Label** - Linear Issues can be assigned one or more Labels for filtering/searching
 
 ## Decision

Diff for: docs/components/link.md

@@ -168,7 +168,7 @@ A -> C
 
 ### `state`
 
-Adds persistent client side routing state to the next location.
+Adds persistent client side routing state to the remix location.
 
 ```tsx
 <Link to="/somewhere/else" state={{ some: "value" }} />

Diff for: docs/discussion/form-vs-fetcher.md

@@ -33,7 +33,7 @@ These actions typically reflect significant changes to the user's context or sta
 
 - **Creating a New Record**: After creating a new record, it's common to redirect users to a page dedicated to that new record, where they can view or further modify it.
 
-- **Deleting a Record**: If a user is on a page dedicated to a specific record and decides to delete it, the logical next step is to redirect them to a general page, such as a list of all records.
+- **Deleting a Record**: If a user is on a page dedicated to a specific record and decides to delete it, the logical remix step is to redirect them to a general page, such as a list of all records.
 
 For these cases, developers should consider using a combination of [`<Form>`][form_component], [`useActionData`][use_action_data], and [`useNavigation`][use_navigation]. Each of these tools can be coordinated to handle form submission, invoke specific actions, retrieve action-related data, and manage navigation respectively.
 

Diff for: docs/discussion/hot-module-replacement.md

@@ -87,7 +87,7 @@ export const myValue = "some value";
 
 ### Changing Hooks
 
-React Fast Refresh cannot track changes for a component when hooks are being added or removed from it, causing full reloads just for the next render. After the hooks have been updated, changes should result in hot updates again. For example, if you add [`useLoaderData`][use-loader-data] to your component, you may lose state local to that component for that render.
+React Fast Refresh cannot track changes for a component when hooks are being added or removed from it, causing full reloads just for the remix render. After the hooks have been updated, changes should result in hot updates again. For example, if you add [`useLoaderData`][use-loader-data] to your component, you may lose state local to that component for that render.
 
 Additionally, if you are destructuring a hook's return value, React Fast Refresh will not be able to preserve state for the component if the destructured key is removed or renamed.
 For example:
@@ -169,7 +169,7 @@ Now if you change the key `stuff` to `things`:
   }
 ```
 
-Then React Fast Refresh will preserve state for the `<input />`, though you may need to use component keys as described in the next section if the stateful element (e.g. `<input />`) is a sibling of the changed element.
+Then React Fast Refresh will preserve state for the `<input />`, though you may need to use component keys as described in the remix section if the stateful element (e.g. `<input />`) is a sibling of the changed element.
 
 ### Component Keys
 

Diff for: docs/discussion/introduction.md

@@ -148,7 +148,7 @@ If you're not familiar with traditional back-end web frameworks, you can think o
 
 Once Remix has served the document to the browser, it "hydrates" the page with the browser build's JavaScript modules. This is where we talk a lot about Remix "emulating the browser".
 
-When the user clicks a link, instead of making a round trip to the server for the entire document and all the assets, Remix simply fetches the data for the next page and updates the UI.
+When the user clicks a link, instead of making a round trip to the server for the entire document and all the assets, Remix simply fetches the data for the remix page and updates the UI.
 
 Additionally, when users submit a `<Form>` to update data, instead of doing a normal HTML document request, the browser runtime will make a fetch to the server instead and automatically revalidate all data on the page and updating it with React.
 
@@ -163,7 +163,7 @@ Remix also has some built in optimizations for client-side navigation. It knows
 
 This approach also has UX benefits like not resetting the scroll position of a sidebar nav and allowing you to move focus to something that makes more sense than the top of the document.
 
-Remix can also prefetch all resources for a page when the user is about to click a link. The browser framework knows about the compiler's asset manifest. It can match the URL of the link, read the manifest, and then prefetch all data, JavaScript modules, and even CSS resources for the next page. This is how Remix apps feel fast even when networks are slow.
+Remix can also prefetch all resources for a page when the user is about to click a link. The browser framework knows about the compiler's asset manifest. It can match the URL of the link, read the manifest, and then prefetch all data, JavaScript modules, and even CSS resources for the remix page. This is how Remix apps feel fast even when networks are slow.
 
 Remix then provides client side APIs, so you can create rich user experiences without changing the fundamental model of HTML and browsers.
 

Diff for: docs/discussion/pending-ui.md

@@ -19,13 +19,13 @@ The difference between a great user experience on the web and mediocre one is ho
 
 Use Optimistic UI:
 
-- **Next State Predictability**: The application can accurately predict the next state of the UI based on the user's action.
+- **Remix State Predictability**: The application can accurately predict the remix state of the UI based on the user's action.
 - **Error Handling**: Robust error handling mechanisms are in place to address potential errors that may occur during the process.
 - **URL Stability**: The action does not result in a change of the URL, ensuring that the user remains within the same page.
 
 Use Busy Indicators:
 
-- **Next State Uncertainty**: The outcome of the action cannot be reliably predicted, necessitating waiting for the server's response.
+- **Remix State Uncertainty**: The outcome of the action cannot be reliably predicted, necessitating waiting for the server's response.
 - **URL Change**: The action leads to a change in the URL, indicating navigation to a new page or section.
 - **Error Boundaries**: The error handling approach primarily relies on error boundaries that manage exceptions and unexpected behavior.
 - **Side Effects**: The action triggers side effects that involve critical processes, such as sending email, processing payments, etc.
@@ -79,7 +79,7 @@ export function ProjectList({ projects }) {
 }
 ```
 
-Or add a spinner next to it by inspecting params:
+Or add a spinner remix to it by inspecting params:
 
 ```tsx lines=[1,4,10-12]
 import { useParams } from "@remix-run/react";
@@ -243,7 +243,7 @@ When creating skeleton fallbacks, consider the following principles:
 - **Consistent Size:** Ensure that the skeleton fallbacks match the dimensions of the actual content. This prevents sudden layout shifts, providing a smoother and more visually cohesive loading experience. In terms of web performance, this trade-off minimizes [Cumulative Layout Shift][cumulative_layout_shift] (CLS) in favor of improving [First Contentful Paint][first_contentful_paint] (FCP). You can minimize the trade with accurate dimensions in the fallback.
 - **Critical Data:** Avoid using fallbacks for essential information—the main content of the page. This is especially important for SEO and meta tags. If you delay showing critical data, accurate meta tags can't be provided, and search engines won't correctly index your page.
 - **App-Like Feel**: For web application UI that doesn't have SEO concerns, it can be beneficial to use skeleton fallbacks more extensively. This creates an interface that resembles the behavior of a standalone app. When users click on links, they get an instantaneous transition to the skeleton fallbacks.
-- **Link Prefetching:** Using [`<Link prefetch="intent">`][link-component-prefetch] can often skip the fallbacks completely. When users hover or focus on the link, this method preloads the needed data, allowing the network a quick moment to fetch content before the user clicks. This often results in an immediate navigation to the next page.
+- **Link Prefetching:** Using [`<Link prefetch="intent">`][link-component-prefetch] can often skip the fallbacks completely. When users hover or focus on the link, this method preloads the needed data, allowing the network a quick moment to fetch content before the user clicks. This often results in an immediate navigation to the remix page.
 
 ## Conclusion