Takes advantage of caching between builds for Terser, also makes writing caches for babel-loader faster by disabling compression.
Results for zeit.co (350 pages):
Without cache:
[4:16:22 PM] Compiled server in 1m
[4:16:57 PM] Compiled client in 2m
✨ Done in 125.83s.
With cache:
[4:19:38 PM] Compiled client in 17s
[4:19:50 PM] Compiled server in 29s
✨ Done in 31.79s.
Note: these results are from my multi-core Macbook Pro 2017, exact specs:
MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports)
- 3,3 GHz Intel Core i5
- 16 GB 2133 MHz LPDDR3
- Intel Iris Plus Graphics 650 1536 MB
The `without cache` build runs uglify in parallel, so without cache is likely to take longer on environments where you have only 1 core available.
The `with cache` build however runs in a single thread, so the results should be similar.
- [x] Move jest config from npm scripts to `jest.config.js`
- [x] Remove obsolete cross-env package (we don't need it anymore 🎉)
- [x] Fix bug where tests are not waiting for webdriver to be ready.
* Update jest
* Let jest start chromedriver
This makes sure chromedriver always ends even if the test was canceled by the user.
* Properly close browser in production-config test
* Properly close browser in production/security test
* Properly close browser in export test
* Properly close browser in app-aspath test
* Remove taskr from project root
This isn’t needed anymore
* Readd taskr to project root (temporary)
* Improve global setup/teardown
* Properly close browser in basic/client-navigation test
Clicking an target=_blank link will open a second browser window. We can only close this by using broser.quit()
* Set a default path for wasm modules
* Added the mimetype "application/wasm" for wasm files
* Upgrade write-file-webpack-plugin to 4.4.1
* Made dynamic(import()) in test to dynamic(() => import())
* Add failing tests
* Upgrade wd module
* Pass dynamic import webpack ids to the client side
* Pass through webpack ids to initalializer and only use those
* Compile dynamic(import()) to dynamic(() => import())
* Default dynamicIds
* Use forked hard-source-plugin
* Possibly fix test
* Make tests fail less intermittently
* Temporarily disable hard-source in production
* Make sure dynamic import chunks are unique
* Disable hard-source
* Log html if error is thrown
* Fix test
Since we are now using webpacks `mode` flag we can get rid of:
* `webpack.optimize.ModuleConcatenationPlugin`
* `webpack.DefinePlugin` (`process.env.NODE_ENV`)
https://webpack.js.org/concepts/mode/
* Add test for /_next/development route
* Make sure useFileSystemPublicRoute: false only disables filesystem routing
* Bring back comment
* Add useFileSystemPublicRoutes tests
## Minor changes
When `NODE_ENV=test` is used we'll now apply the `'auto'` configuration for modules transformation. Which causes Babel to check if the current environment needs to be transformed or not. In practice this means that the following `.babelrc` is not needed anymore:
**OLD**:
```json
{
"env": {
"development": {
"presets": ["next/babel"]
},
"production": {
"presets": ["next/babel"]
},
"test": {
"presets": [["next/babel", { "preset-env": { "modules": "commonjs" } }]]
}
}
}
```
**NEW**:
```
{
"presets": ["next/babel"]
}
```
## Patches
`@babel/preset-react` has a `development` option that automatically applies a development-time plugin we manually applied before (`@babel/plugin-transform-react-jsx-source`). It also adds another development-time plugin that is said to make debugging/errors clearer: `@babel/plugin-transform-react-jsx-self` which we didn't apply before. Overall this means we can take advantage of preset-react to provide these plugins.
Currently, using `as` will cause the router to think the URL is not changing in the case where you're re-rendering the same page with a different route. This would most likely be an issue for custom servers
which are using shallow routing.
This should be an invisible change for non-custom-server users, since `as` is defaulted to `url` if not set.
This should resolve#3065.
Fixes#5038
The problem with `constructor` is that it doesn't have `context` yet when being called. It's also considered unsafe to add a side-effect on constructor except when server-rendering
~I am not sure if this is a valid fix yet, but I was going to let CI run the tests for me. I'll close and look into it if the build fails.~
Let me know if this will cause issues, but I don't think it should. The React docs recommends moving `componentWillMount` logic into the constructor
- [x] Add unit test
- [x] Allow to get the display name of a native component (e.g.: `div`) without throwing
- [ ] Remove displayName in production mode
`<Container>` does not receive any property. There is no way the *scrollToHash* logic can work right now. I believe it's a regression. It was working fine at some point. I'm sorry, I'm too lazy to add a test.
This fix was tested on Material-UI 👌.
This bug reproduction is the following:
As soon as you want to transition to a new page with a hash. The scroll doesn't change.
- start on pageA
- you scrollTop to 100
- you move to pageB#hash
- you stay at scrollTop 100, but #hash is at scrollTop 400.
* Throw error if getInitialProps is defined as as instance method
Omitting the static keyword happens pretty often. Therefore we should trigger a warning in devmode.
Closes: #4782
* Document getInitialProps error
* Add unit tests for loadGetInitialProps
