Next.js 6.1: Hot Reloading, Codemods, and a Cleaner Codebase
Next.js 6.1 is now available as a production-ready release. This version focuses on bringing development behavior closer to production, simplifying how custom file extensions are handled in the pages directory, and automating the migration away from a deprecated API. The team also announced that nextjs.org itself is now open source, available on GitHub as a reference implementation.
Hot Reloading Without react-hot-loader
Previous versions of Next.js automatically included react-hot-loader to preserve React state across hot reloads. However, that library introduced non-standard behaviors, such as ignoring shouldComponentUpdate and wrapping components in proxy elements instead of using the real component types.
In 6.1, Next.js drops react-hot-loader as a dependency to keep development mode as close to default React behavior as possible. Hot reloading itself remains fully supported — it has always been managed internally by Next.js and continues to work as before.
Automatic Hot Reloading for Custom Page Extensions
Next.js has historically treated files in the pages directory as routes, checking for .js and .jsx by default. Since the introduction of universal webpack in Next.js 5, plugins have been able to extend this to other extensions. For example, @zeit/next-typescript adds .ts and .tsx to that list, while @zeit/next-mdx allows top-level .mdx pages.
Previously, plugins that customized the pageExtensions option in next.config.js also had to implement the hot-self-accept-loader for their custom extensions to reload properly. That is no longer necessary — Next.js 6.1 applies the loader automatically whenever a custom extension is registered via pageExtensions.
Internal Restructuring
Several behind-the-scenes changes in 6.1 are meant to improve maintainability. The server/build directory is now at the top-level build, making webpack and babel configurations easier to locate for contributors. Flow types are being added throughout the codebase, and repeated constants have been consolidated into a single constants.js file.
One user-visible change: build output that previously lived in .next/dist now lives in .next/server. When running next build, the pre-rendering files will be stored in that new location.
Automated Migration with next-codemod
Next.js 6 deprecated the automatically injected url property on page components. The goal is to make data access more explicit and predictable. The recommended replacement is withRouter, which injects a router property exposing the same information.
// Before (Next.js < 6)
export default class Page extends React.Component {
render() {
return <p>{this.props.url.pathname}</p>
}
}
// After (Next.js 6+)
import { withRouter } from 'next/router'
class Page extends React.Component {
render() {
return <p>{this.props.router.pathname}</p>
}
}
export default withRouter(Page)
To simplify upgrading, the team has released next-codemod, a collection of automated transformation scripts. The first available codemod is url-to-withrouter, which rewrites common url usage patterns to use withRouter in a single command.
npx next-codemod url-to-withrouter pages
Becoming a Contributor
Next.js has grown to more than 450 contributors. The project accepts community involvement through several routes: offering advice and examples in GitHub Discussions, adding use-case examples to the examples directory, and tackling issues labeled good first issue or help wanted.
Future Directions
Work is already underway on features aimed at improving speed and reducing operational overhead. One focus is Webpack 4, whose optimizations have shown meaningful gains in initial tests. For an app with over 200 pages, average next build times dropped from about 100 seconds to 70 seconds; run again with caches, build times fell further to around 21 seconds.
Another initiative is preparing next start to move into its own dedicated package, next-server. That package is intended to be optimized for install size and boot time, which directly addresses the "serverless" use case where a new application instance is started on every request — cold starts need to be extremely fast.
