c021662d1e
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.
|
||
|---|---|---|
| .. | ||
| mocks | ||
| pages | ||
| public | ||
| .gitignore | ||
| package.json | ||
| README.md | ||
Mock Service Worker Example
Mock Service Worker is an API mocking library for browser and Node. It provides seamless mocking by interception of actual requests on the network level using Service Worker API. This makes your application unaware of any mocking being at place.
In this example we integrate Mock Service Worker with Next by following the next steps:
- Define a set of request handlers shared between client and server.
- Setup a Service Worker instance that would intercept all runtime client-side requests via
setupWorkerfunction. - Setup a "server" instance to intercept any server/build time requests (e.g. the one happening in
getServerSideProps) viasetupServerfunction.
Mocking is enabled using the NEXT_PUBLIC_API_MOCKING environment variable, which for the sake of the example is saved inside .env instead of .env.development. In a real app you should move the variable to .env.development because mocking should only be done for development.
Deploy your own
Deploy the example using Vercel:
How to use
Execute create-next-app with npm or Yarn to bootstrap the example:
npx create-next-app --example with-msw with-msw-app
# or
yarn create next-app --example with-msw with-msw-app
Deploy it to the cloud with Vercel (Documentation).