next.js: No TypeScript error overlay in development after updating to 9.4

Bug report

I updated nextjs from 9.3.6 to 9.4.0.

Describe the bug

After updating I do not get typescript errors anymore checked during buildtime. This was working in 9.3.6.

To Reproduce

As I have quite a complex mono repository, I’m unable to provide the source of that. Major differences to a stock configuration is a custom babel configuration:

module.exports = {
  presets: [],
  plugins: [
    'lodash',
    '@babel/proposal-class-properties',
    'react-intl-auto',
    'babel-plugin-graphql-tag'
  ],
  env: {
    test: {
     presets: [
       '@babel/typescript',
         [ '@babel/preset-env',
           {
           targets: {
             node: process.versions.node
           }
         }
         ],
       '@babel/preset-react'
     ]
    },
    nodeTs: {
      presets: [
        '@babel/typescript',
        '@babel/preset-react',
        [
          '@babel/preset-env',
          {
            targets: {
              node: process.versions.node
            }
          }
        ]
      ]
    },
    nextjs: {
      presets: ['next/babel']
    }
  }
}

And a custom next.config.ts:

/* eslint-disable @typescript-eslint/no-var-requires */
const path = require('path')

const withDevTool = (nextConfig: any = {}) => {
  return {
    ...nextConfig,
    webpack(config: any, options: any) {
      const { dev } = options
      if (dev) {
        config.devtool = 'eval-source-map'
      }
      if (typeof nextConfig.webpack === 'function') {
        return nextConfig.webpack(config, options)
      }
      return config
    },
  }
}

export default () => {
  const optimizedImages = require('next-optimized-images')

  const withTM = require('next-transpile-modules')([
    'query-string',
    'imask/esm',
   /** ..some more private modules */
  ])

  const withCustomBabelConfigFile = require('next-plugin-custom-babel-config')
  const withCSS = require('@zeit/next-css')

  const withBundleAnalyzer = require('@next/bundle-analyzer')({
    enabled: process.env.ANALYZE === 'true',
  })

  return withDevTool(
    withBundleAnalyzer(
      optimizedImages(
        withCustomBabelConfigFile(
          withCSS(
            withTM({
              babelConfigFile: path.resolve(
                path.join(__dirname, '../../../../babel.config.js')
              ),
              distDir: 'dist',
            })
          )
        )
      )
    )
  )
}

I’m using a custom server with additional express middleware.

// This file doesn't go through babel or webpack transformation.
// Make sure the syntax and sources this file requires are compatible with the current node version you are running
// See https://github.com/zeit/next.js/issues/1245 for discussions on Universal Webpack or universal Babel
import 'dotenv/config'
import express from 'express'
import next from 'next'
import { defaultMiddleware } from '../index'
import { appConfig } from './appConfig'

const applicationFactory = (): void => {
  const dev = process.env.NODE_ENV !== 'production'
  const conf = dev
    ? // eslint-disable-next-line @typescript-eslint/no-var-requires
      require('./next.config').default()
    : {
        distDir: 'dist',
      }
  const app = next({
    dev,
    conf,
  })
  const handle = app.getRequestHandler()
  app.prepare().then(() => {
    const server = express()
    const proxyInstance = defaultMiddleware(server, appConfig)
    server.get('*', (req, res) => {
      return handle(req, res)
    })
    const port = process.env.PORT || 3000
    // @ts-ignore
    const listener = server.listen(port, (err: Error) => {
      if (err) {
        throw err
      }
      // tslint:disable-next-line:no-console
      console.log(`> Ready on http://localhost:${port}`)
    })
    listener.on('upgrade', (req: any, socket: any, ...rest: any) => {
      socket.on('error', (error: any) => {
        console.error(error)
      })
      proxyInstance.upgrade(req, socket, ...rest)
    })
  })
}

export default applicationFactory

Expected behavior

Typescript errors should be reported.

System information

  • OS: Windows
  • Version of Next.js: 9.4.0
  • Version of Node.js: 12.13.1

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 2
  • Comments: 15 (7 by maintainers)

Commits related to this issue

Most upvoted comments

Please add an option to enable typescript checks for the whole code during development

Hello! This is intended as part of the new Fast Refresh experience. We wanted to make updates visible as fast as possible, without interrupting your train of thought for a type error.

We feel type checking in development is better done passively by your editor!

Plus, we can recover from runtime errors now so it’s not necessary to pass type checking to test your application (a runtime error won’t cause you to lose application state).

Type checking is still performed during your production build.

Hey @Timer it looks like you should update this as well:

By default, Next.js reports TypeScript errors during development for pages you are actively working on. TypeScript errors for inactive pages do not block the development process.

And I’d love it if you could shy away from being opinionated like this:

We feel type checking in development is better done passively by your editor!

Some of us (e.g. @tvandort and I) really like seeing the errors as soon as they come up. You should add an option (and document it) to turn them back on.

@Timer, sorry, but it has not: https://nextjs.org/docs/api-reference/next.config.js/ignoring-typescript-errors

I just spent 20 minutes debugging and bisecting to find out where I lost TypeScript errors. I checked that page beforehand.

I also had previously read all of the 9.4 release notes. It’d be really helpful to point big dev workflow changes out in release notes so we’re not caught by them. The team had relied on those errors and when they disappeared they just assumed all was well when it wasn’t. It cost us some time.

Yes, the option has been completely removed. We’ll update the docs to reflect this.

After upgrading I added additional type checking in the console. Maybe someone will find this solution useful.

next.config.js

/* eslint-disable @typescript-eslint/no-var-requires */

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');

module.exports = {
  /**
   * Custom Webpack Config
   * https://nextjs.org/docs/api-reference/next.config.js/custom-webpack-config
   */
  webpack(config, options) {
    const { dev, isServer } = options;

    // Do not run type checking twice:
    if (dev && isServer) {
      config.plugins.push(
        new ForkTsCheckerWebpackPlugin()
      );
    }

    return config;
  },
};

While I appreciate that some might want to disable the type error overlay in order to not have some break in flow, I do feel that there must be others like myself who use Typescript to force breaks in train of thought.

Part of the reason why I opt into typescript is to immediately stop me if I’ve broken some assumption somewhere. While the editor can catch these errors, sometimes refactoring code can lead to changes across multiple files. An editor can report these but it’s often hard to catch. Issues created in such changes can be difficult given that a file with issues might not be open.

For the moment I realized that the type error overlay can still be enabled by disabling fast refresh in next.config.js like so:

module.exports = {
  experimental: {
    reactRefresh: false 
  }
}

I assume this flag will be removed in the near future. At that point I guess I’ll have to attach some other type checking plugin to the webpack overrides assuming such a thing is possible.

I also thought it was an error on my end after upgrading. It might be worth it to update the docs for TypeScript to call out this change. The TypeScript section of the docs here currently says:

By default, Next.js reports TypeScript errors during development for pages you are actively working on. TypeScript errors for inactive pages do not block the development process.

In addition to that adding ignoreDevErrors: false to the config seems to have no effect as well, so is the option to see TypeScript errors during development completely removed?

Hi 😃 thank you for clarification. Makes sense to me, although maybe it should be mentioned in the Blogpost / Changelog, just to prevent questions like that?. I thought it was an error. As the editor sometimes takes quite a while to update the error state (due to the size of the project), not getting the feedback on the build was suprising. Besides that, Fast Refresh is awesome. Thank you!!

@timneutkens I updated version 9.4.2. And I again lost type checking. Are you kidding me? Is that how the patch version is changed?

What the hell is an experimental feature is breaking the whole stack?

I put up with it, In 9.4+. But now on 9.4.2, even if I turn experimental.reactRefresh off, there’s still no checks!

Can you give normal guide - how i can enable typescript checks forever!

This has been removed from the docs, closing. I’d highly suggest not re-adding the plugin as it makes development really slow.

I also thought it was an error on my end after upgrading. It might be worth it to update the docs for TypeScript to call out this change. The TypeScript section of the docs here currently says:

By default, Next.js reports TypeScript errors during development for pages you are actively working on. TypeScript errors for inactive pages do not block the development process.

In addition to that adding ignoreDevErrors: false to the config seems to have no effect as well, so is the option to see TypeScript errors during development completely removed?

I had the exact same experience. I decided to add Typescript support to my project but noticed typescript errors weren’t being flagged by the new error overlay and thought it might be related to a misconfiguration on my end (especially because I use a custom server); the documentation seemed to confirm this suspicion.