Skip to content

Deprecation warning for experimental.turbo with Next.js plugins (e.g. @next/mdx) #78009

@amannn

Description

@amannn

Link to the code that reproduces this issue

amannn/nextjs-bug-repro-turbo-deprecation-warning@a8d9981

To Reproduce

Run pnpm run dev

Current vs. Expected behavior

This warning is printed:

 ⚠ The config property `experimental.turbo` is deprecated. Move this setting to `config.turbopack` as Turbopack is now stable.

I'd expect no warning to be printed.

Provide environment information

Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64
  Available memory (MB): 16384
  Available CPU cores: 12
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 1.22.22
  pnpm: 9.15.4
Relevant Packages:
  next: 15.3.0 // Latest available version is detected (15.3.0).
  eslint-config-next: 15.3.0
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Markdown (MDX), Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local)

Additional context

This causes the deprecation warning:

nextConfig.experimental = Object.assign({}, nextConfig?.experimental, {
turbo: Object.assign({}, nextConfig?.experimental?.turbo, {
rules: Object.assign({}, nextConfig?.experimental?.turbo?.rules, {
'*.mdx': {
loaders: [loader],
as: '*.tsx',
},
}),

I think, ideally, Next.js should provide an environment parameter, an exported property (like React.version) or similar that allows plugins to read the Next.js version number. This would help plugins to adjust configuration based on this.

Note that this not only affects the MDX plugin but also other downstream plugins like next-intl (amannn/next-intl#1838)

Especially with the announcement of experimental.turbo being removed in a future major version, it would be great if downstream plugins wouldn't be forced to release a major version as well in response, but could adjust the config based on Next.js' version number.

The closest I can think of would be to use require.resolve('next') to get a path to the Next.js dependency folder and from there traverse upwards to find the closest package.json and read the version from there. I might be missing some edge cases here though, so an official way would be preferable from my perspective.

Metadata

Metadata

Assignees

Labels

Markdown (MDX)Related to Markdown with Next.js.TurbopackRelated to Turbopack with Next.js.linear: turbopackConfirmed issue that is tracked by the Turbopack team.locked

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions