Tackling major Next.js upgrades

Published in

Turo Engineering

5 min readAug 26, 2022

At Turo, our front-end team leverages Next.js alongside a content management system to create a series of pages specifically for SEO purposes. With each major Next upgrade, we have witnessed significant improvements in our Google Lighthouse scores, and the Next team consistently puts out exciting and top notch upgrades. Nonetheless, neither the move to Next 11 nor Next 12 came without its battles for our team.

Beginning with Next 11, it was not as simple as following the directions within the Next upgrading documentation. We use Preact alongside Next, and with it, prefresh, which allows for fast-refresh with Preact. Upon bumping Next to v11, and trying to run a build in the project, we encountered a cryptic prefresh related error:

TypeError: Cannot read property ‘framework’ of undefined.

Through a number of Google searches and some digging, we encountered a Github issue open within next-plugin-preact that mentioned the above error.

When we first started using Next we followed an example from Next’s GitHub repository for using Preact alongside the framework. It did not utilize next-plugin-preact, and we have not made this switch ourselves. However, as the error we encountered matched the same one from the next-plugin-preact issue, we were curious whether the answer to our questions could be in the thread.

There is a comment in the thread that mentions Next changed a Webpack splitChunks.cacheGroups configuration. For context, Webpack is a module bundler for JS applications and it packages all the modules in an application into a bundle to serve it to the browser. It is what Next uses under the hood to bundle their code. A splitChunks configuration helps Webpack break a JS bundle into different chunks. This allows to avoid loading a single bundle over the network all at once and avoids loading code that might not be needed as well. Cache groups can inherit and/or override any options from splitChunks.¹

The comment suggests how next-plugin-preact would need to be fixed, and we noticed this code looked very similar to the example we had to use to get Next running with Preact initially. After implementing the suggested fix in the code we had pulled from the Next/Preact example, our project built again and we saw some great performance improvements. We were able to reduce our Webpack maxEntrypointSize² by over 20% , and some of our most visited pages saw significant Lighthouse performance score rises with our homepage 20% higher, our car-rental page 70% higher, and Honolulu, one of most popular destinations, 60% higher.

Onto Next 12

We were optimistic upgrading to Next 12 would be more straight forward than Next 11, but this quickly proved not to be the case.

In order to run Next 12 we needed to bump our typescript version, which in turn required us to bump our package manager, Yarn Berry@2.4.3. This is required because the only way yarn 2+ supports new Typescript versions is by creating new pnp patches that are rolled out with minor versions. Unfortunately, support for the new required TS version (4.4.3) wasn’t rolled out in yarn 2.4.3, only yarn 3.1.1. So, while this worked in a local environment within our Next project, when we tried to build our other JS packages in our front-end monorepo we encountered an npm error:

typescript@npm:4.4.3 can't be found in the cache and will be fetched from the remote registry

Once again, we took to Github issues to decipher the error, and came across this Yarn issue which mentions a similar npm error was resolved by upgrading to Yarn 3. So, we tried updating to Yarn 3, but again this prevented us from generating a successful build in our Next application as we encountered yet another error. Through more digging we learned that with Yarn 3, support for ESM modules was introduced for the package manager, which triggered a Node bug that caused the breaking build. Fortunately, as this issue points out, we could resolve the error by upgrading to a Node version greater than v16.14.

At this point, we opted to take the opportunity to upgrade Node across all our JS packages in our front-end monorepo, and with the changes, we finally had a working version of Next 12. Again, we saw drastic improvements in Lighthouse performance, with our homepage score rising another 20% and our car-rental page up another 15% as well.

The future with Next

As Turo continues to use Next on the front-end, it has become quite apparent the value of keeping Node, package managers, and dependencies up to date to avoid headaches when dealing with major upgrades. We look forward to Next 13, and hope we are in a better place than the last two upgrades to take advantage of its new advances and features.

Thanks for reading!

We are hiring

Interested in joining our awesome front-end team at Turo?. Help us build product features that delight guests who book vehicles on our platform and enable hosts with the tools they need to manage their cars.