Merge branch 'release-next' into dev

Author: brophdawg11

.changeset/blocker-key-strict-mode.md

@@ -4,7 +4,7 @@
 
 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.
+- Make sure you've pulled all the changes from GitHub for both `dev` and `main` branches.
 - Check out the `dev` branch.
 - 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.
@@ -17,7 +17,7 @@ Changesets will do most of the heavy lifting for our releases. When changes are
 
 - 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 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 {} \;`
@@ -30,27 +30,27 @@ You may need to make changes to a pre-release prior to publishing a final stable
 - 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.
+- Commit the changesets and push the `release-*` branch to GitHub.
 - 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 edited pre-release file along with any unpublished changesets, and push the the `release-*` branch to GitHub.
+- Commit the edited 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]
-- Prepare the github release notes
+- Prepare the GitHub release notes
   - Copy the relevant changelog entries from all packages into the Release Notes and adjust accordingly, matching the format used by prior releases
 - 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 `v6.x.y`
+  - Convert the `[email protected]` tag to a Release on GitHub with the name `v6.x.y`
 
 ### Hotfix releases
 

.changeset/formdata-submitter.md

@@ -1,5 +1,6 @@
 - 0xEddie
 - abdallah-nour
+- abeadam
 - abhi-kr-2100
 - AchThomas
 - adamdotjs
@@ -140,6 +141,7 @@
 - markivancho
 - maruffahmed
 - marvinruder
+- mathpaquette
 - matt-harro
 - maxpou
 - mcansh

.changeset/purple-islands-cough.md

@@ -96,28 +96,44 @@ submit([
 ]);
 ```
 
-The default behavior if you submit a JSON object is to encode the data into `FormData`:
+The default behavior if you submit a JSON object for a POST submission is to encode the data into `FormData`:
 
 ```tsx
-submit({ key: "value", { encType: "application/x-www-form-urlencoded" });
+submit(
+  { key: "value" },
+  {
+    method: "post",
+    encType: "application/x-www-form-urlencoded",
+  }
+);
 // will serialize into request.formData() in your action
+// and will show up on useNavigation().formData during the navigation
 ```
 
 Or you can opt-into JSON encoding:
 
 ```tsx
-submit({ key: "value" }, { encType: "application/json" });
+submit(
+  { key: "value" },
+  { method: "post", encType: "application/json" }
+);
 // will serialize into request.json() in your action
+// and will show up on useNavigation().json during the navigation
 
-submit('{"key":"value"}', { encType: "application/json" });
+submit('{"key":"value"}', {
+  method: "post",
+  encType: "application/json",
+});
 // will encode into request.json() in your action
+// and will show up on useNavigation().json during the navigation
 ```
 
 Or plain text:
 
 ```tsx
-submit("value", { encType: "text/plain" });
+submit("value", { method: "post", encType: "text/plain" });
 // will serialize into request.text() in your action
+// and will show up on useNavigation().text during the navigation
 ```
 
 ## Submit options
@@ -126,8 +142,8 @@ The second argument is a set of options that map (mostly) directly to form submi
 
 ```tsx
 submit(null, {
-  action: "/logout",
   method: "post",
+  action: "/logout",
 });
 
 // same as

.changeset/raw-payload-submission-router.md

@@ -57,7 +57,7 @@ ReactDOM.createRoot(document.getElementById("root")).render(
 
 We recommend all web projects use [`createBrowserRouter`][createbrowserrouter].
 
-It uses the full URL instead of the hash urls (`#this/stuff`) common in web apps before `window.pushState` was standardized. Full URLs are better for SEO, better for server rendering, and are just more compatible with the rest of the web platform.
+It uses the full URL instead of the hash urls (`#this/stuff`) common in web apps before `history.pushState` was standardized. Full URLs are better for SEO, better for server rendering, and are just more compatible with the rest of the web platform.
 
 If you're hosting your app on a static file server, you'll need to configure it to send all requests to your `index.html` to avoid getting 404s.
 

.changeset/raw-payload-submission.md

@@ -118,7 +118,7 @@
       "none": "16.2 kB"
     },
     "packages/react-router-dom/dist/react-router-dom.production.min.js": {
-      "none": "12.5 kB"
+      "none": "12.6 kB"
     },
     "packages/react-router-dom/dist/umd/react-router-dom.production.min.js": {
       "none": "18.6 kB"

.changeset/skip-fetcher-revalidate.md

@@ -1,5 +1,14 @@
 # `react-router-dom-v5-compat`
 
+## 6.14.0
+
+### Patch Changes
+
+- Upgrade `typescript` to 5.1 ([#10581](https://github.com/remix-run/react-router/pull/10581))
+- Updated dependencies:
+  - `[email protected]`
+  - `[email protected]`
+
 ## 6.13.0
 
 ### Patch Changes

.changeset/smart-pots-repair.md

@@ -1,6 +1,6 @@
 {
   "name": "react-router-dom-v5-compat",
-  "version": "6.13.0",
+  "version": "6.14.0",
   "description": "Migration path to React Router v6 from v4/5",
   "keywords": [
     "react",
@@ -24,7 +24,7 @@
   "types": "./dist/index.d.ts",
   "dependencies": {
     "history": "^5.3.0",
-    "react-router": "6.13.0"
+    "react-router": "6.14.0"
   },
   "peerDependencies": {
     "react": ">=16.8",