What’s new in Nuxt 2.7

NuxtJS is a free and open source web application framework based on Vue.js, Node.js, Express.js, Webpack, and Babel.js. It is one of the most popular frameworks for creating VueJS applications. With NuxtJS, you can choose between universal, static generation or single page applications.
With over 20,000 ⭐️ on GitHub and a host of dedicated community members constantly providing support, building highly performant, stable and efficient VueJS applications that have features of a SSRA and SPA has never been easier.

Since its initial release, several versions that address issues and add features have also been subsequently released by its maintainers. More recently, version 2.7 just came out the door with several updates that solve various pain points and make improvements to existing features.
In this tutorial, we will go over some of the recent changes and how they can help us develop better applications using NuxtJS.

N/B: This tutorial assumes a basic understanding of VueJS and NuxtJS. To learn more visit the links here and here.

SSR (universal rendering) logs in your browser

Typically, when debugging universal applications (server + client) a common method used to see the result of a piece of code is done using console.log. This is efficient (it does the job) but a big pain point is that it splits the result of the log to either the terminal (when logging server-specific code) or browser (when logging client-specific code) which can be pretty annoying since you have to switch screens from your browser to client to see the result.

Starting with NuxtJS v2.7 this is no longer the case. All SSR logs are now reported to your browser console. You no longer have to switch screens, you can now see the result of all your logs in your browser.

Automatic detecting of store directory creation

Stores help in managing states in big applications. NuxtJS implements Vuex by default. Previously, to activate a store you create a store directory and NuxtJS will:

• Import Vuex
• Add the store option to the root Vue instance.

However, for this to happen you will have to restart it. In v2.7, you no longer have to do this as NuxtJS now detects when you create a store/ directory and will reload itself automatically so you don’t have to restart it anymore.
The serverMiddleware watch has been improved to restart NuxtJS and clean their cache.

Extending babel.presets and babel envName API

Presets can act as an array of Babel plugins or sharable options config. When you don’t want to assemble your own set of plugins, babel-preset-app is the default preset used by Nuxt, It is mainly a wrapper around the @babel/preset-env preset.
Typically customizing babel config is done through a .babelrc or config file. In NuxtJS v2.7 babel.rc file is ignored by default in favor of the build.extend API. Now, passing options to babel is done using this new API like this:

// nuxt.config.js
export default {
  build: {
    babel: {
      presets({ isServer }, [preset, options]) {
        // change options directly
        options.targets = ...
        options.corejs = ...

        // or return whole preset list
      }
    }
  }
}

An envName API has also been added for use with the configFile:

// nuxt.config.js
export default {
  build: {
    babel: {
      configFile: path.resolve(rootDir, 'babel.config.js')
    }
  }
}

// babel.config.js
module.exports = function (api) {
  const env = api.env()
  api.cache.using(() => env)

  const presets = []
  const plugins = []

  if (env === 'server') {
    // set server presets/plugins
  } else if (env === 'client') {
    // set client presets/plugins
  } else if (env === 'modern') {
    // set modern presets/plugins
  }

  return { presets, plugins }
}

Configurable aliases

When working with webpack it is not uncommon to create aliases in your webpack config. Prior to v2.7, configuring aliases from the config file wasn’t configurable. You would have to use the @ symbol in front of your alias name. This means conflicts would arise if you already had a similar configuration in your config.

// packages/webpack/src/config/base.js
alias() {
    const { srcDir, rootDir, dir: { assets: assetsDir, static: staticDir } } = this.buildContext.options

    return {
      '~': path.join(srcDir),
      '~~': path.join(rootDir),
      '@': path.join(srcDir),
      '@@': path.join(rootDir),
      [assetsDir]: path.join(srcDir, assetsDir),
      [staticDir]: path.join(srcDir, staticDir)
   }
}

This issue no longer exists in v2.7 as it is now configurable. Aliases will now be defined in the options object in the options.js file and referenced in the base.js file thereby removing potential conflicts.

Ignore “not found” warnings

When working with TypeScript export ... was not found ... is a common error that occurs. Even though it doesn’t stop your app from running it’s pretty annoying to see it pop up.
Previously, such errors can be suppressed by adding a custom plugin to the nuxt.config.ts. However, from NuxtJS v2.7 the feature has been added to NuxtJS core.

N/B: For a concrete list of all changes check out the release page

Deprecation

The following APIs have been deprecated in NuxtJS v2.7:

• NuxtJS v2.7 dropped support for node < 8.6 relate to \[**ts-loader v6**\](https://github.com/TypeStrong/ts-loader/releases/tag/v6.0.0) (Only for TypeScript users)
• The transition property (now depreciated) has been renamed to **pageTransition** in nuxt.config.js for clarity when transitioning between pages and layouts

Future-use warnings

• The transition property will no longer be available in NuxtJS v3.

MIGRATION TIP: You don’t need to change a single line of code in your project for any effects. Everything will be automatically migrated as soon as you upgrade to NuxtJS v2.7.

Conclusion

In this tutorial, we explored some new features and improvements in NuxtJS v2.7. We also looked at some deprecated features and future warnings. To see a concrete list of all changes and to know more about the new releases be sure to check out the release page. Keep a lookout for our next post on NuxtJS v2.8. Happy Coding!