When using the `with-msw` example I noticed it increased my bundle size in production, even through MSW is meant to be used in development only.
**Build size before implementing MSW**
```
Page Size First Load JS
┌ λ / 479 B 58.9 kB
├ /_app 0 B 58.4 kB
└ ○ /404 3.44 kB 61.9 kB
+ First Load JS shared by all 58.4 kB
├ chunks/f6078781a05fe1bcb0902d23dbbb2662c8d200b3.b1b405.js 10.3 kB
├ chunks/framework.cb05d5.js 39.9 kB
├ chunks/main.a140d5.js 7.28 kB
├ chunks/pages/_app.b90a57.js 277 B
└ chunks/webpack.e06743.js 751 B
λ (Server) server-side renders at runtime (uses getInitialProps or getServerSideProps)
○ (Static) automatically rendered as static HTML (uses no initial props)
● (SSG) automatically generated as static HTML + JSON (uses getStaticProps)
(ISR) incremental static regeneration (uses revalidate in getStaticProps)
```
**Build size after implementing MSW according to the `with-msw` example**
```
Page Size First Load JS
┌ λ / 479 B 71.6 kB
├ /_app 0 B 71.1 kB
└ ○ /404 3.44 kB 74.6 kB
+ First Load JS shared by all 71.1 kB
├ chunks/f6078781a05fe1bcb0902d23dbbb2662c8d200b3.b1b405.js 10.3 kB
├ chunks/framework.cb05d5.js 39.9 kB
├ chunks/main.a140d5.js 7.28 kB
├ chunks/pages/_app.c58a6f.js 13 kB
└ chunks/webpack.e06743.js 751 B
λ (Server) server-side renders at runtime (uses getInitialProps or getServerSideProps)
○ (Static) automatically rendered as static HTML (uses no initial props)
● (SSG) automatically generated as static HTML + JSON (uses getStaticProps)
(ISR) incremental static regeneration (uses revalidate in getStaticProps)
```
There was a 12.7 kB large increase in the `_app` First Load JS which increased the pages' First Load JS size. I tracked the problem down to the following code:
```js
if (process.env.NEXT_PUBLIC_API_MOCKING === 'enabled') {
require('../mocks')
}
```
Removing this reduces the `_app` First Load JS to what it was previously. The `NEXT_PUBLIC_API_MOCKING` environment variable is defined in the `.env.development` file, as this means that Next.js will only activate MSW during development/testing, which is what MSW is intended for.
After discussing with @kettanaito, the author of MSW, I did some investigation. This dynamic require statement is intended to allow tree-shaking of the MSW package for production. Unfortunately this did not seem to be working. To fix this, I changed the code to the following:
```js
if (process.env.NODE_ENV !== 'production') {
require('../mocks')
}
```
This means I could remove the `NEXT_PUBLIC_API_MOCKING` environment variable from `.env.development`, as it is no longer used.
It is important to note that this still achieves the same functionality as before: MSW runs in development / testing, and not in production. If MSW must be enabled in production for some reason, the following code can be used to run MSW regardless of the environment:
```js
if (true) {
require('../mocks')
}
```
If possible, I'd love to hear from the Next.js maintainers regarding the tree-shaking process when using environment variables.
Lastly, I made the necessary changes to have the example work in production mode as well, because there is no real backend. Of course there is a comment explaining what should be changed in a real world app.
Follow-up PR to https://github.com/vercel/next.js/pull/17370 when the path is not prefixed with a locale and the default locale is the detected locale it doesn't redirect to locale prefixed variant. If the default locale path is visited and the default locale is visited this also redirects to the root removing the un-necessary locale in the URL.
This also exposes the `defaultLocale` on the router since the RFC mentions `Setting a defaultLocale is required in every i18n library so it'd be useful for Next.js to provide it to the application.` although doesn't explicitly spec where we want to expose it. If we want to expose it differently this can be updated.
This adds the initial changes outlined in the [i18n routing RFC](https://github.com/vercel/next.js/discussions/17078). This currently treats the locale prefix on routes similar to how the basePath is treated in that the config doesn't require any changes to your pages directory and is automatically stripped/added based on the detected locale that should be used.
Currently redirecting occurs on the `/` route if a locale is detected regardless of if an optional catch-all route would match the `/` route or not we may want to investigate whether we want to disable this redirection automatically if an `/index.js` file isn't present at root of the pages directory.
TODO:
- [x] ensure locale detection/populating works in serverless mode correctly
- [x] add tests for locale handling in different modes, fallback/getStaticProps/getServerSideProps
To be continued in fall-up PRs
- [ ] add tests for revalidate, auto-export, basePath + i18n
- [ ] add mapping of domains with locales
- [ ] investigate detecting locale against non-index routes and populating the locale in a cookie
x-ref: https://github.com/vercel/next.js/issues/17110
Follow-up to https://github.com/vercel/next.js/pull/17533 this makes sure the file used to signal release stats should be skipped for a non-release merge is created in a location that is accessible by the stats action and also updates the release action info detection for the new workflow
Noticed this method was left-over from previous query handling logic in `api-utils` while working on https://github.com/vercel/next.js/pull/17370 so this removes the extra code which should be safe since `api-utils` is an internal file that shouldn't be relied on externally.
Noticed while adding config checks for a new config that the `basePath` checks were wrapped in a `result.experimental` check and even though this should always be true from the default experimental value being an object the `basePath` checks shouldn't be wrapped in this check since it isn't experimental anymore.
Wrong variable was being checked for the hydrate action on redux. This was causing the count to be reset to 0 instead of being 1 when initially loading index.js page.
Fixes#17299
Prior to this pull request, Next.js would immediately decode all URLs sent to its server (via `path-match`).
This was rarely needed, and Next.js would typically re-encode the incoming request right away (see all the `encodeURIComponent`s removed in PR diff). This adds unnecessary performance overhead.
Long term, this will also help prevent weird encoding edge-cases like #10004, #10022, #11371, et al.
---
No new tests are necessary for this change because we've extensively tested these edge cases with existing tests.
One test was updated to reflect that we skip decoding in a 404 scenario.
Let's see if all the existing tests pass!
This is a change to add the project name as in the other examples.
When we run with the current create command, we are asked for the project name.
As follows:
```
$ npx create-next-app --example with-three-js
? What is your project named? › my-app
```
This PR removes "vercel.json" from the Yarn workspaces example. Since the release of [monorepos](https://vercel.com/blog/monorepos) support, there is no need to use the "builds" property or "vercel.json".
