Next.js 5.1: Faster Page Resolution

To upgrade or install, run:

npm i next@latest react@latest react-dom@latest

Be sure to upgrade next-plugins like @zeit/next-css, @zeit/next-sass, @zeit/next-less or @zeit/next-typescript as well.

Link to headingFaster page resolution

Thanks to the architectural changes in Next.js 5.0, we were able to simplify the logic that resolves pages based on url path. These changes were based on research from @oliviertassinari.
Previously resolving a page took an average of 2.347ms. With the new logic resolving the same page takes on average 0.023ms. That's a 102x speedup for one of the most commonly invoked methods in Next.js applications.

Link to headingEnvironment configuration

Typical Node.js environments often depend on passing environment variables to the application, for example: API_URL=https://api.zeit.co node index.js and then you can use API_URL anywhere in your application using process.env.API_URL.

With universal rendering process.env is not available on the client side. So with Next 5.1 we're introducing a new feature: publicRuntimeConfig and serverRuntimeConfig. These can be set in next.config.js and will then be available using the next/config module.

1
module.exports = {
2
  serverRuntimeConfig: { // Will only be available on the server side
3
    mySecret: 'secret'
4
  },
5
  publicRuntimeConfig: { // Will be available on both server and client
6
    staticFolder: '/static'
7
  }
8
}

1
import getConfig from 'next/config'
2
const {serverRuntimeConfig, publicRuntimeConfig} = getConfig()
3

4
console.log(serverRuntimeConfig.mySecret) // Will only be available on the server side
5
console.log(publicRuntimeConfig.staticFolder) // Will be available on both server and client
6

7
export default () => <div>
8
  <img src='\${publicRuntimeConfig.staticFolder}/logo.png' />
9
</div>

Link to headingImproved Error Handling

Previously Next.js had a special error handling mechanism for detecting server errors when loading page bundles. A page bundle is the javascript file that is loaded on the client side to load the page, for example /_next/-/page/index.js.

If there were an error, like a build ID mismatch, the page bundle would still be served with a 200 HTTP status, but the contents would be a JSON representation of an error generated by the Next.js server. The reason for this is that there was client side error handling that depended on more than just the page being a 404. This solution worked really well, until you try to upload assets to a static file host or CDN that doesn't support a fallback.

With Next.js 5.1 we've completely refactored the error handling logic, when a page bundle returns a 404 HTTP status the router will automatically detect it and reload the page, to make sure navigation between multi-zones is possible.

In rewriting this logic, we removed the Router.onAppUpdated hook; which was mainly used to trigger a page reload. Now the page will be automatically reloaded

In addition to this, we've added a new set of integration tests on error recovery in the development mode, to avoid regressions on error recovery in future releases.

Link to headingPhases / config function

Some next-plugins like @zeit/next-css are only required when Next.js is in development mode or when running next build.

You can now export a function that returns the configuration object instead of immediately exporting the object.

module.exports = (phase, {defaultConfig}) => config

Exporting a function will give you access to the phase in which Next.js is running, for example development, production, building, export. This allows plugins to be loaded only when needed, but also gives access to the default configuration.

We've introduced a new module called next/constants holding commonly used constants, including phases.

1
const {PHASE_DEVELOPMENT_SERVER} = require('next/constants')
2
module.exports = (phase, {defaultConfig}){
3
  if(phase === PHASE_DEVELOPMENT_SERVER) {
4
    return { /* development only config options here */ }
5
  }
6

7
  return { /* config options for all phases except development here */ }
8
}

Link to headingImproved production source map generation

With the introduction of universal webpack in Next.js 5 adding source maps to your production environment became as simple as adding a few lines to next.config.js:

1
module.exports = {
2
  webpack(config, {dev}) {
3
    if (!dev) {
4
      config.devtool = 'source-map';
5
      for (const plugin of config.plugins) {
6
        if (plugin['constructor']['name'] === 'UglifyJsPlugin') {
7
          plugin.options.sourceMap = true;
8
          break;
9
        }
10
      }
11
    }
12
    return config
13
  }
14
}

@zeit/next-source-maps can be added to a project to automatically enable production source maps for you, add the following to next.config.js:

1
const withSourceMaps = require('@zeit/next-source-maps')
2
module.exports = withSourceMaps()

This enabled outputting of source maps for all but one file, app.js, the reason for this was that app.js consisted of multiple files (manifest.js and commons.js) combined with a webpack plugin. A side effect of this was that webpack couldn't generate source maps for the combined file.

Thanks to a pull request from @ptomasroos the app.js file was replaced by main.js. This file will hold the code that was previously compiled to manifest.js and commons.js and webpack will generate a source map for main.js. Source maps will be automatically served, allowing external error tracking tools to show the actual file and line number when errors are detected.

Link to headingNew plugins / improvements to existing ones

We've introduced two new official plugins. @zeit/next-bundle-analyzer allows for easily setting up webpack-bundle-analyzer to analyze the server side and client side bundles separately.

Additionally there were a lot of improvements to the official css, less, and sass plugins regarding hot reloading and bundling. For example there is no longer a flash of unstyled content in development mode. And styles in subcomponents get picked up as well.

Link to headingThank you

We would like to thank everyone who has contributed to Next.js for this release. Whether it's contributing to the core or expanding and improving our ever growing examples directory.

If you are looking to start contributing to Next.js you can find issues with the good first issue or help wanted label.

A special thank you to Trulia for their valuable feedback related to environment configuration and the new error page handling.