Next.js 7 | Next.js

After 26 canary releases and 3.4 million downloads, we are proud to introduce the production-ready Next.js 7, featuring:
Finally, we are excited to be sharing this news on the all-new Nextjs.org
One of Next.js's primary goals is to provide the best production performance with the best possible developer experience. This release brings about many significant improvements to the build and debug pipelines
Thanks to webpack 4, Babel 7 and many improvements and optimizations on our codebase, Next.js now boots up to 57% faster during development.
Thanks to our new incremental compilation cache, changes you make to the code will now build 40% faster.
These are some example figures we have collected:
As a bonus, when developing and building you will now see better realtime feedback thanks to webpackbar:
Rendering accurate and help errors is critical to a great development and debugging experience. Until now, we would render the error message and its stack trace. Moving forward, we make use of react-error-overlay to enrich the stack trace with:
This is a comparison of the before and after of our errors:
As a bonus, react-error-overlay makes it easy to open your text editor by just clicking on a specific code block.
Since its very first release Next.js has been powered by webpack for bundling your code and re-using the rich ecosystem of plugins and extensions. We're excited to announce Next.js is now powered by the latest webpack 4, which comes with numerous improvements and bugfixes.
Another new feature is WebAssembly support, Next.js can even server-render WebAssembly, here is an example.
Note: this upgrade is fully backwards-compatible. However, if you are using custom webpack loaders or plugins via next.config.js, you might have to upgrade them.
With webpack 4, a new way of extracting CSS from bundles was introduced, called mini-extract-css-plugin.
@zeit/next-css, @zeit/next-less, @zeit/next-sass, and @zeit/next-stylus are now powered by mini-extract-css-plugin.
The new version of these Next.js plugins solves 20 existing issues related to CSS imports; As an example, importing CSS in dynamic import()s is now supported:
A major improvement is that you are no longer required to add the following to pages/_document.js:
Instead, Next.js automatically injects the CSS file. In production, Next.js also automatically adds a content hash to the CSS URL, so that if there are changes, to ensure that your end-users never get stale versions of the file and have the ability to introduce immutable permanent caching.
In short, all you have to do to support importing .css files in your Next.js project is to just register the withCSS plugin in your next.config.js:
Next.js has had support for dynamic imports through next/dynamic since Version 3.
As early adopters of this technology, we had to write our own solution for handling import().
As a consequence, Next.js was beginning to diverge from the support that webpack later introduced for it and some features were missing.
Because of this Next.js did not support a few import() features webpack has introduced since.
For example, naming and bundling certain files together manually was not possible:
Another example is using import() without being wrapped in the next/dynamic module.
Starting with Next.js 7 we no longer touch the default import() behavior. This means you get full import() support out of the box.
This change is fully backwards-compatible as well. Making use of a dynamic component remains as simple as:
What this example does is create a new JavaScript file for my-component and only load it when <MyComponent /> is rendered.
Most importantly, if it is not rendered, the <script> tag is not included in the initial HTML document payload.
To further simplify our codebase and make use of the excellent React ecosystem, in Next.js 7 next/dynamic was re-written to make use of react-loadable behind the scenes (with some minor modifications). This also introduces two great new features for dynamic components:
Next.js 6 introduced Babel 7 while it was still in beta. Since then the stable version of Babel 7 has been released, and Next.js 7 now using this version.
For a full list of changes, you can refer to Babel its release notes.
Some of the main features are:
If you do not have a custom Babel configuration in your Next.js project, there are no breaking changes.
If you do however have a custom Babel configuration, you have to upgrade the respective custom plugins/presets to their latest version.
In case you are upgrading from a version below Next.js 6 you can run the excellent babel-upgrade tool.
In addition to upgrading to Babel 7, the Next.js Babel preset (next/babel) now defaults to setting the modules option to commonjs when NODE_ENV is set to test.
This configuration option was often the only reason for creating a custom .babelrc in a Next.js project:
With Next.js 7 this becomes:
At this point, the .babelrc can be removed, as Next.js will then automatically use next/babel when there is no Babel configuration.