Merge branch 'dev' into release-next

Author: mjackson

.changeset/eighty-dolls-juggle.md

@@ -0,0 +1,5 @@
+---
+"@react-router/dev": patch
+---
+
+Enable prerendering for resource routes

.changeset/serious-beds-approve.md

@@ -0,0 +1,5 @@
+---
+"@react-router/dev": patch
+---
+
+resolve config directory relative to flat output file structure

.github/workflows/shared-build.yml

@@ -22,6 +22,8 @@ jobs:
           node-version-file: ".nvmrc"
           cache: "pnpm"
 
+      - uses: google/wireit@setup-github-actions-caching/v2
+
       - name: Disable GitHub Actions Annotations
         run: |
           echo "::remove-matcher owner=tsc::"

.github/workflows/shared-integration.yml

@@ -45,6 +45,8 @@ jobs:
           node-version: ${{ matrix.node }}
           cache: "pnpm"
 
+      - uses: google/wireit@setup-github-actions-caching/v2
+
       - name: Disable GitHub Actions Annotations
         run: |
           echo "::remove-matcher owner=tsc::"

.github/workflows/test.yml

@@ -45,6 +45,8 @@ jobs:
           cache: pnpm
           check-latest: true
 
+      - uses: google/wireit@setup-github-actions-caching/v2
+
       - name: Disable GitHub Actions Annotations
         run: |
           echo "::remove-matcher owner=tsc::"

.gitignore

@@ -22,6 +22,7 @@ node_modules/
 /packages/*/dist/
 /packages/*/LICENSE.md
 
+.wireit
 .eslintcache
 .tmp
 /.env

DEVELOPMENT.md

@@ -22,15 +22,17 @@ Changesets will do most of the heavy lifting for our releases. When changes are
   - `git commit -a -m "Enter prerelease mode"`
   - `git push --set-upstream origin release-next`
 - Wait for the release workflow to finish - the Changesets action will open a PR that will increment all versions and generate the changelogs
-- Check out the PR branch created by changesets locally
-- _Optional:_ Review the updated `CHANGELOG.md` files in the PR locally and make any adjustments necessary, then merge the PR into the `release-next` branch.
-  - `find packages -name 'CHANGELOG.md' -mindepth 2 -maxdepth 2 -exec code {} \;`
-  - Usually for prereleases there's not much to change here because the prerelease sections will be deleted prior to the final stable release anyway
+- If you need/want to make any changes to the `CHANGELOG.md` files, you can do so and commit directly to the PR branch
+  - This is usually not required for prereleases
 - Once the changesets files are in good shape, merge the PR to `release-next`
 - Once the PR is merged, the release workflow will publish the updated `X.Y.Z-pre.*` packages to npm
+
+### Prepare the draft release notes
+
 - At this point, you can begin crafting the release notes for the eventual stable release in the root `CHANGELOG.md` file in the repo
   - Copy the template for a new release and update the version numbers and links accordingly
   - Copy the relevant changelog entries from all packages into the release notes and adjust accordingly
+    - `find packages -name 'CHANGELOG.md' -mindepth 2 -maxdepth 2 -exec code {} \;`
   - Commit these changes directly to the `release-next` branch - they will not trigger a new prerelease since they do not include a changeset
 
 ### Iterating a pre-release
@@ -96,15 +98,24 @@ After the `6.25.0` release, we branched off a `v6` branch for continued `6.x` wo
 - Once the stable release is out:
   - Merge `release-v6` back to `v6` with a **Normal Merge**
   - **Do not** merge `release-v6` to `main`
-  - Copy the updated changelog entry for the `6.X.Y` version to `main`
+  - Copy the updated root `CHANGELOG.md` entry for the `6.X.Y` release to `main` and `dev`
+    - `git checkout main`
+    - `git diff [email protected]@6.X.Y -- "***CHANGELOG.md" > ./docs.patch`
+    - `git apply ./docs.patch`
+    - `git checkout dev`
+    - `git apply ./docs.patch`
+    - `rm ./docs.patch`
   - Copy the docs changes to `main` so they show up on the live docs site for v6
     - `git checkout main`
     - `git diff [email protected]@6.X.Y docs/ > ./docs.patch`
     - `git apply ./docs.patch`
-  - The _code_ changes should already be in the `dev` branch but confirm that the commits in this release are all included in `dev` already:
-    - I.e., https://github.com/remix-run/react-router/compare/[email protected]@6.26.2
-    - If one or more are not, then you can manually bring them over by cherry-picking the commit (or re-doing the work)
-    - You should not include a changelog in your commit to `dev`
+    - `rm ./docs.patch`
+  - The _code_ changes should already be in the `dev` branch
+    - This should have happened at the time the v6 change was made (except for changes such as deprecation warnings)
+    - Confirm that the commits in this release are all included in `dev` already:
+      - I.e., https://github.com/remix-run/react-router/compare/[email protected]@6.26.2
+      - If one or more are not, then you can manually bring them over by cherry-picking the commit (or re-doing the work)
+      - You should not include a changelog in your commit to `dev`
   - Copy the updated changelogs from `release-next` over to `dev` so the changelogs continue to reflect this new 6x release into the v7 releases
 
 ### Notes on 7.0.0-pre.N released during the v7 prerelease

build.utils.ts

@@ -0,0 +1,12 @@
+export function createBanner(packageName: string, version: string) {
+  return `/**
+ * ${packageName} v${version}
+ *
+ * Copyright (c) Remix Software Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE.md file in the root directory of this source tree.
+ *
+ * @license MIT
+ */`;
+}

decisions/0011-routes-ts.md

@@ -92,4 +92,4 @@ As of the creation of this decision document, the only available build context i
 
 ### Remix's `routes` option has an adapter for easy migration
 
-Some Remix consumers used the `routes` option to define config-based routes or use community file system routing conventions. To ease the migration, the `@react-router/remix-config-routes-adapter` package provides a `remixConfigRoutes` function that accepts Remix's `routes` config value as an argument.
+Some Remix consumers used the `routes` option to define config-based routes or use community file system routing conventions. To ease the migration, the `@react-router/remix-routes-option-adapter` package provides a `remixRoutesOptionAdapter` function that accepts Remix's `routes` config value as an argument.

docs/start/testing.md

@@ -5,7 +5,7 @@ order: 9
 
 # Testing
 
-When components use things like `useLoaderData`, `<Link>`, etc, they are required to be rendered in context of a React Router app. The `createStub` function creates that context to test components in isolation.
+When components use things like `useLoaderData`, `<Link>`, etc, they are required to be rendered in context of a React Router app. The `createRoutesStub` function creates that context to test components in isolation.
 
 Consider a login form component that relies on `useActionData`
 
@@ -32,19 +32,20 @@ export function LoginForm() {
 }
 ```
 
-We can test this component with `createStub`. It takes an array of objects that resemble route modules with loaders, actions, and components.
+We can test this component with `createRoutesStub`. It takes an array of objects that resemble route modules with loaders, actions, and components.
 
 ```tsx
-import { createStub, route } from "react-router/testing";
+import { createRoutesStub } from "react-router";
 import * as Test from "@testing-library/react";
 import { LoginForm } from "./LoginForm";
 
 test("LoginForm renders error messages", async () => {
   const USER_MESSAGE = "Username is required";
   const PASSWORD_MESSAGE = "Password is required";
 
-  const Stub = createStub([
-    route("/login", {
+  const Stub = createRoutesStub([
+    {
+      path: "/login",
       Component: LoginForm,
       action() {
         return {