Error when accessing Typescript enum defined outside Next root in Next 9.4

[majelbstoat]

Bug report

Accessing a typescript enum property when the file defining the enum is outside Next's directory causes issues in Next 9.4.0 and Next 9.4.1, but not in Next 9.3.6.

Describe the bug

Defining a Typescript enum in a .ts file outside the root causes issues running next if any property is accessed on the enum.

The error implies that the file was not parsed correctly:

../lib/common/types.ts 1:7
Module parse failed: Unexpected token (1:7)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
> export enum MyEnum {
|   OPTION_ONE = 1,
|   OPTION_TWO = 2,

This was not a problem in Next 9.3.6.

It's hard to describe, so I put together a minimal reproduction: https://github.com/majelbstoat/nextjs-broken-enums

Expected behavior

Typescript is compiled correctly, and I can access properties on enums.

System information

• OS: [macOS]
• Version of Next.js: [9.4.0, 9.4.1]
• Version of Node.js: [12.16.1]

Additional context

This broke in 9.4.0, and I originally thought it was the definition itself that caused the problem because that's what the error implied (#12786) but that was a symptom, not the root issue.

[Timer]

This is the expected behavior because you're importing a file outside of your application root. TypeScript files are not processed there.

You'll need to override your webpack configuration to compile the top-level lib, or move the files into your app root.

[majelbstoat]

This worked without issue, in exactly the same manner, in 9.3.6.

They can't be moved inside because they are shared files with other projects.

[Timer]

Hmm, nothing should've changed in that regard. Do you have a next.config.js in your project?

Note your provided example also fails with 9.3.6.

[majelbstoat]

Ah, yes, I do! It has this in it to support symlinks:

function supportSymlinkedFilesInNextBabelLoader(config) {
  config.module.rules.forEach(({ use }, i) => {
    const isBabelLoader = use && use.loader === "next-babel-loader";
    if (isBabelLoader) {
      delete config.module.rules[i].include;
    }
  });
}

module.exports = {
  webpack: function (config, { isServer }) {
    // Add support symlinks for dev.
    supportSymlinkedFilesInNextBabelLoader(config);
    if (!config.resolve) {
      config.resolve = {};
    }
    config.resolve.symlinks = false;
  },
};

Any chance next-babel-loader is not the name of the loader any more?

[Timer]

use could be an array, so you need to search deeper.

[majelbstoat]

The problem actually appears to be that next-babel-loader is no longer used for the client?

With 9.3.6, use-babel-loader is used twice, once each for server and client:

{
  loader: 'next-babel-loader',
  options: {
    isServer: false, // Client
    distDir: '/dev/nextjs-broken-enums/app/.next',
    pagesDir: '/dev/nextjs-broken-enums/app/pages',
    cwd: '/dev/nextjs-broken-enums/app',
    cache: true,
    babelPresetPlugins: [],
    hasModern: false,
    development: true,
    hasReactRefresh: false
  }
}
{
  loader: 'next-babel-loader',
  options: {
    isServer: true, // Server
    distDir: '/dev/nextjs-broken-enums/app/.next',
    pagesDir: '/dev/nextjs-broken-enums/app/pages',
    cwd: '/dev/nextjs-broken-enums/app',
    cache: true,
    babelPresetPlugins: [],
    hasModern: false,
    development: true,
    hasReactRefresh: false
  }
}

But for 9.4.1, it's only used for the server:

{
  loader: 'next-babel-loader',
  options: {
    isServer: true, //Server
    distDir: '/dev/nextjs-broken-enums/app/.next',
    pagesDir: '/dev/nextjs-broken-enums/app/pages',
    cwd: '/dev/nextjs-broken-enums/app',
    cache: true,
    babelPresetPlugins: [],
    hasModern: false,
    development: true,
    hasReactRefresh: false
  }
}

Is that a deliberate change?

(Because it's not called on the client, I can't update the include path to make it handle Typescript outside the root)

[Timer]

It's still used for the client, but you need to handle the case when use is an array.

[majelbstoat]

Ah, I see. Yeah, awesome, that got it, thanks.

For those who have a similar issue, or come here from (#3898), my updated config is:

function supportSymlinkedFilesInNextBabelLoader(config) {
  config.module.rules.forEach(({ use }, i) => {
    if (!use) return
    const isBabelLoader = Array.isArray(use)
      ? use.findIndex((item) => item && item.loader && item.loader === 'next-babel-loader') !== -1
      : use.loader === 'next-babel-loader'
    if (isBabelLoader) {
      delete config.module.rules[i].include
    }
  })
}

[DayBr3ak]

@majelbstoat can we have the full config? Do you have any babel dependencies? I can't get it to work.

I'm stumped nextjs can't parse an enum correctly.

[Timer]

@DayBr3ak Next.js can parse enums just fine. This is a bug with your custom configuration or code, so you'll need to provide a full demo for us to find the issue in your project.