* 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/
Fixes#5125
I'm not sure if this is a bug in babel-loader / babel-core or not. But this will at least temporary fix it till I hear back from @loganfsmyth 🙏
Probably an oversight but currently env preset's `modules` option always evaluates to 'auto'. We probably want it to be set to false, especially in prod, to have Webpack handle modules natively.
## 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.
* Implement autodllplugin
* Add flow-typed for autodll-webpack-plugin
* Improve onClick tests
* Make third test pass
* Make sure DLL bundle is loaded without async
* Add nonce
* Fix windows DLL path
Fixes#4691Fixes#4614
This PR gives path to https://github.com/zeit/next-plugins/pull/242
I did not add or remove `^` near dependency versions in package.json files. However, I don't exclude that some changes can be made given that rc is more stable than beta.
## Context
When upgrading to Next.js 6.1.1-canary.4 and using the `emit-file-loader` included in Next.js, the following error is thrown:
```bash
error in ./src/graveyard/pages/_app.scss
Module build failed (from ../node_modules/next/dist/build/webpack/loaders/emit-file-loader.js):
TypeError: Cannot read property 'context' of undefined
at Object.module.exports (~/project-root/node_modules/next/dist/build/webpack/load
ers/emit-file-loader.js:27:68)
@ ./src/pages/_app.js 35:0-53 156:17-26 157:13-22
@ multi ./pages/_app.js
```
`next.config.js` (shortened):
```js
module.exports = {
webpack: (config, { dev }) => {
config.module.rules.push({
test: /\.scss$/,
use: [
{
loader: 'emit-file-loader',
options: {
name: 'dist/[path][name].[ext].js'
}
},
{
loader: 'babel-loader',
options: {
babelrc: false,
extends: path.resolve(__dirname, './src/.babelrc')
}
},
'styled-jsx-css-loader',
{ loader: 'postcss-loader', options: { sourceMap: dev } },
{
loader: 'sass-loader',
options: {
sourceMap: dev
}
}
]
});
return config;
}
};
```
## Suggested Fix
A quick Google search brought me to a [related issue in `webpack-loader`](https://github.com/webpack-contrib/worker-loader/issues/125). As pointed out in the [Webpack docs](https://webpack.js.org/api/loaders/#this-rootcontext):
> Starting with webpack 4, the formerly `this.options.context` is provided as `this.rootContext`.
This PR makes this change while maintaining backward compatibility.
## System information
Next.js: 6.1.1-canary.4
Node: v9.3.0
Depends on https://github.com/zeit/next-plugins/pull/228
Failing tests are expected as `@zeit/next-css` has to be updated/released first.
This implements rendering of `.css` chunks. Effectively removing the custom document requirement when adding next-css/sass/less/stylus.
* Compile pages to .next/static/<buildid>/pages/<page>
* Fix test
* Export class instead of using exports
* Use constant for static directory
* Add comment about what the middleware does
Fixes#4686
Adds tests for @zeit/next-typescript so that we don't regress on this again.
I've fixed an issue in the `next` CLI too which caused lingering processes when the process gets force killed, which is what we do in the test suite, so it kept running if there was no manual quit.
I have spend whole day on profiling next.js compiling performance and one of the easy hacks to reduce built time is avoid doing full `stats.toJson()` that is heavy by default.
This makes sure plugins like @zeit/next-typescript or @zeit/next-mdx don't have to provide the `hot-self-accept-loader`.
This fixes for example @zeit/next-mdx, which doesn't implement `pageExtensions` but we do use mdx as top level pages for https://github.com/zeit/docs
The prepares for next-server.
I also took this as an opportunity to get all build directory paths from a single location, as they were previously scattered across webpack/babel plugins and loaders.
