Merge branch 'release-next' into dev

.github/workflows/lint.yml

@@ -27,6 +27,11 @@ jobs:
       - name: 📥 Install deps
         run: yarn --frozen-lockfile
 
+      - name: Disable Eslint GitHub Actions Annotations
+        run: |
+          echo "::remove-matcher owner=eslint-compact::"
+          echo "::remove-matcher owner=eslint-stylish::"
+
       - name: 🔬 Lint
         run: yarn lint
 

.github/workflows/reusable-test.yml

@@ -82,7 +82,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: 🛑 Cancel Previous Runs
-        uses: styfle/cancel-workflow-action@0.10.0
+        uses: styfle/cancel-workflow-action@0.11.0
 
       - name: ⬇️ Checkout repo
         uses: actions/checkout@v3
@@ -113,7 +113,7 @@ jobs:
     runs-on: macos-latest
     steps:
       - name: 🛑 Cancel Previous Runs
-        uses: styfle/cancel-workflow-action@0.10.0
+        uses: styfle/cancel-workflow-action@0.11.0
 
       - name: ⬇️ Checkout repo
         uses: actions/checkout@v3

DEVELOPMENT.md

@@ -33,44 +33,54 @@ yarn test react --watch
 
 ## Releases
 
-New releases should be created from release branches originating from `dev`. When you are ready to begin the release process:
+New releases should be created from release branches originating from the `dev` branch. When you are ready to begin the release process:
 
+- Make sure you've pulled all of the changes from GitHub for both `dev` and `main` branches.
 - Check out the `dev` branch.
-- Pull all of the changes from GitHub.
-- Create a new release branch with the `release-` prefix (eg, `git checkout -b release-next`)
+- Create a new release branch with the `release-` prefix (eg, `git checkout -b release-next`).
   - **IMPORTANT:** The `release-` prefix is important, as this is what triggers our GitHub CI workflow that will ultimately publish the release.
   - Branches named `release-experimental` will not trigger our release workflow, as experimental releases handled differently (outlined below).
+- Merge `main` into the release branch.
 
 Changesets will do most of the heavy lifting for our releases. When changes are made to the codebase, an accompanying changeset file should be included to document the change. Those files will dictate how Changesets will version our packages and what shows up in the changelogs.
 
 ### Starting a new pre-release
 
 - Ensure you are on the new `release-*` branch.
 - Enter Changesets pre-release mode using the `pre` tag: `yarn changeset pre enter pre`.
-- Commit the change and push the the `release-*` branch to GitHub.
+- Commit the change and push the `release-*` branch to GitHub.
 - Wait for the release workflow to finish. The Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs.
-- Review the PR, make any adjustments necessary, and merge it into the `release-*` branch.
+- Review the updated `CHANGELOG` files and make any adjustments necessary, then merge the PR into the `release-*` branch.
+  - `find packages -name 'CHANGELOG.md' -mindepth 2 -maxdepth 2 -exec code {} \;`
 - Once the PR is merged, the release workflow will publish the updated packages to npm.
 
-### Incrementing a pre-release
+### Iterating a pre-release
 
 You may need to make changes to a pre-release prior to publishing a final stable release. To do so:
 
 - Make whatever changes you need.
 - Create a new changeset: `yarn changeset`.
   - **IMPORTANT:** This is required even if you ultimately don't want to include these changes in the logs. Remember, changelogs can be edited prior to publishing, but the Changeset version script needs to see new changesets in order to create a new version.
 - Commit the changesets and push the the `release-*` branch to GitHub.
-- Wait for the release workflow to finish and the Changesets action to open its PR.
+- Wait for the release workflow to finish and the Changesets action to open its PR that will increment all versions.
 - Review the PR, make any adjustments necessary, and merge it into the `release-*` branch.
 - Once the PR is merged, the release workflow will publish the updated packages to npm.
 
 ### Publishing the stable release
 
 - Exit Changesets pre-release mode: `yarn changeset pre exit`.
-- Commit the deleted pre-release file along with any unpublished changesets, and push the the `release-*` branch to GitHub.
-- Wait for the release workflow to finish. The Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs.
-- Review the PR. We should remove the changelogs for all pre-releases ahead of publishing the stable version. [TODO: We should automate this]
+- Commit the deleted pre-release file along with any unpublished changesets, and push the `release-*` branch to GitHub.
+- Wait for the release workflow to finish. The Changesets action in the workflow will open a PR that will increment all versions and generate the changelogs for the stable release.
+- Review the updated `CHANGELOG` files and make any adjustments necessary.
+  - We should remove the changelogs for all pre-releases ahead of publishing the stable version.
+  - [TODO: We should automate this]
+- Merge the PR into the `release-*` branch.
 - Once the PR is merged, the release workflow will publish the updated packages to npm.
+- Once the release is published:
+  - merge the `release-*` branch into `main` and push it up to GitHub
+  - merge the `release-*` branch into `dev` and push it up to GitHub
+  - Convert the `[email protected]` tag to a Release on Github with the name `v1.x.y`
+  - Copy the relevant changelog entries from all packages into the Release Notes and adjust accordingly, matching the format used by prior releases
 
 ### Experimental releases
 

contributors.yml

@@ -245,6 +245,7 @@
 - jwnx
 - kalch
 - kamtugeza
+- kandros
 - kanermichael
 - karimsan
 - kauffmanes
@@ -457,6 +458,7 @@
 - thomasheyenbrock
 - thomasrettig
 - tjefferson08
+- tombiju
 - tombyrer
 - toyozaki
 - turkerdev
@@ -486,6 +488,7 @@
 - wKovacs64
 - wladiston
 - wtlin1228
+- wxh06
 - xHomu
 - XiNiHa
 - xstevenyung

docs/file-conventions/route-files-v2.md

@@ -324,7 +324,7 @@ routes/
   app_.projects.$id.roadmap.tsx
 ```
 
-Some, or all of them can be folders holding their own modules inside.
+Some, or all of them can be folders holding their own `route` module inside.
 
 ```
 routes/
@@ -359,7 +359,7 @@ routes/
   contact-us.tsx
 ```
 
-Note that `app/index.tsx` is _not_ the "index route" for `app/`. It is Note's "index module" for the directory `routes/app/`. The index route for `app/` is `app._index/index.tsx`. The only thing that contributes to the route path is the directory name.
+Note that when you turn a route module into a folder, the route module becomes `folder/route.tsx`, all other modules in the folder will not become routes. For example:
 
 ```
 # these are the same route:

docs/guides/constraints.md

@@ -119,7 +119,7 @@ export default function Posts() {
 }
 ```
 
-The loader is gone but the prisma dependency stayed! Had we logged something harmless like `console.log("hello!")` it would be fine. But we logged the `prisma` module so the browser's gonna have a hard time with that.
+The loader is gone but the prisma dependency stayed! Had we logged something harmless like `console.log("hello!")` it would be fine. But we logged the `prisma` module so the browser's going to have a hard time with that.
 
 To fix this, remove the side effect by simply moving the code _into the loader_.
 

docs/guides/data-loading.md

@@ -314,7 +314,7 @@ Given the following URLs, the search params would be parsed as follows:
 
 ### Data Reloads
 
-When multiple nested routes are rendering and the search params change, all of the routes will be reloaded (instead of just the new or changed routes). This is because search params are a cross-cutting concern and could effect any loader. If you would like to prevent some of your routes from reloading in this scenario, use [shouldReload][should-reload].
+When multiple nested routes are rendering and the search params change, all of the routes will be reloaded (instead of just the new or changed routes). This is because search params are a cross-cutting concern and could effect any loader. If you would like to prevent some of your routes from reloading in this scenario, use [shouldRevalidate][should-revalidate].
 
 ### Search Params in Components
 
@@ -667,7 +667,7 @@ There are three cases where Remix will reload all of your routes:
 - If the url search params change (any loader could use them)
 - The user clicks a link to the exact same URL they are already at (this will also replace the current entry in the history stack)
 
-All of these behaviors emulate the browser's default behavior. In these cases, Remix doesn't know enough about your code to optimize the data loading, but you can optimize it yourself with [unstable_shouldReload][should-reload].
+All of these behaviors emulate the browser's default behavior. In these cases, Remix doesn't know enough about your code to optimize the data loading, but you can optimize it yourself with [shouldRevalidate][should-revalidate].
 
 ## Data Libraries
 
@@ -746,7 +746,7 @@ export default function RouteComp() {
 [prisma]: https://prisma.io
 [request]: https://developer.mozilla.org/en-US/docs/Web/API/Request
 [search-params-getall]: https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/getAll
-[should-reload]: ../route/should-reload
+[should-revalidate]: ../route/should-revalidate
 [url-search-params]: https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams
 [url]: https://developer.mozilla.org/en-US/docs/Web/API/URL
 [use-submit]: ../hooks/use-submit

docs/hooks/use-fetchers.md

@@ -74,7 +74,7 @@ This is awesome for the checkbox, but the sidebar will say 2/4 while the checkbo
 +-----------------+----------------------------┘
 ```
 
-Because Remix will automatically reload the routes, the sidebar will quickly update and be correct. But for a moment, it's gonna feel a little funny.
+Because Remix will automatically reload the routes, the sidebar will quickly update and be correct. But for a moment, it's going to feel a little funny.
 
 This is where `useFetchers` comes in. Up in the sidebar, we can access all the inflight fetcher states from the checkboxes - even though it's not the component that created them.
 

docs/other-api/adapter.md

@@ -26,6 +26,8 @@ Each adapter has the same API. In the future we may have helpers specific to the
 
 ## Community Adapters
 
+- [`@mcansh/remix-fastify`][remix-fastify] - For [Fastify][fastify].
+- [`@mcansh/remix-raw-http`][remix-raw-http] - For a good ol barebones Node server.
 - [`remix-google-cloud-functions`][remix-google-cloud-functions] - For [Google Cloud][google-cloud-functions] and [Firebase][firebase-functions] functions.
 
 ## Creating an Adapter
@@ -180,3 +182,6 @@ addEventListener("fetch", (event) => {
 [remix-google-cloud-functions]: https://github.com/penx/remix-google-cloud-functions
 [google-cloud-functions]: https://cloud.google.com/functions
 [firebase-functions]: https://firebase.google.com/docs/functions
+[remix-fastify]: https://github.com/mcansh/remix-fastify
+[fastify]: https://www.fastify.io
+[remix-raw-http]: https://github.com/mcansh/remix-node-http-server

docs/tutorials/blog.md

@@ -202,7 +202,7 @@ A solid practice is to create a module that deals with a particular concern. In
 touch app/models/post.server.ts
 ```
 
-We're mostly gonna copy/paste stuff from our route:
+We're mostly going to copy/paste stuff from our route:
 
 ```tsx filename=app/models/post.server.ts
 type Post = {
@@ -534,7 +534,7 @@ export default function PostSlug() {
 }
 ```
 
-Holy smokes, you did it. You have a blog. Check it out! Next, we're gonna make it easier to create new blog posts 📝
+Holy smokes, you did it. You have a blog. Check it out! Next, we're going to make it easier to create new blog posts 📝
 
 ## Nested Routing
 
@@ -700,7 +700,7 @@ Now click the link from the index route and watch the `<Outlet/>` automatically
 
 ## Actions
 
-We're gonna get serious now. Let's build a form to create a new post in our new "new" route.
+We're going to get serious now. Let's build a form to create a new post in our new "new" route.
 
 💿 Add a form to the new route