2020-08-14 18:47:54 +02:00
|
|
|
{
|
|
|
|
|
"name": "with-msw",
|
|
|
|
|
"version": "1.0.0",
|
|
|
|
|
"scripts": {
|
|
|
|
|
"dev": "next",
|
|
|
|
|
"build": "next build",
|
|
|
|
|
"start": "next start"
|
|
|
|
|
},
|
|
|
|
|
"license": "MIT",
|
|
|
|
|
"dependencies": {
|
Fix with-msw example (#17695)
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.
2020-10-08 20:19:29 +02:00
|
|
|
"msw": "^0.21.2",
|
2020-08-14 18:47:54 +02:00
|
|
|
"next": "latest",
|
|
|
|
|
"react": "^16.13.1",
|
|
|
|
|
"react-dom": "^16.13.1"
|
|
|
|
|
}
|
|
|
|
|
}
|
