"Experimental features" warning should be configurable via flag

[markerikson]

What version of Next.js are you using?

11.0 (but applies to all)

What version of Node.js are you using?

N/A

What browser are you using?

N/A

What operating system are you using?

N/A

How are you deploying your application?

N/A

Describe the Bug

If the next.config.js file contains a key named experimental, Next.js always prints a warning message on startup, like:

warn  - You have enabled experimental feature(s).
warn  - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use them at your own risk.

There is currently no way to disable this warning.

FWIW I searched the existing issues and discussions, and surprisingly did not see an issue covering this topic yet.

Expected Behavior

The warning should be configurable via some kind of an override flag in next.config.js, such as:

module.exports =  {
    experimental: {
      externalDir: true
    },
    // Potential new config flag:
    disableExperimentalFeaturesWarning: true
}

To Reproduce

1. Create a new Next project
2. Add a next.config.js file
3. Add a field named experimental with any known experimental flag, per the Next docs

[switz]

This would be super handy. I may want to disable these on a per feature basis rather than swallowing all warnings.

Might we do [in pseudo types]:

experimental: {
    externalDir: true | {
        enabled: true,
        silent: true,
   },
};

[gaearon]

I'm curious, what's the purpose of disabling the warning? From my perspective, the whole point of the warning is to make it impossible to start the app without an acknowledgement that you're relying on prerelease features.

[tatleung]

One issue I am having is the warning messages are being written to the stdout which causes my build automation process to incorrectly interpret them as errors. It would be very helpful to change it to info message so they are not written to stdout.

[markerikson]

I explicitly acknowledged that I was using an "experimental feature" when I wrote the key experimental in my config file.

I don't need to be reminded of that every time the app starts up in both development and production builds.

On top of that, we use the next-page-tester library to do "integration"-style tests of an entire page route at a time.... and every single test that loads a page is printing out these console warnings.

I was already hijacking console.log() to filter out some warnings in certain tests, including the ever-popular "useLayoutEffect can't be used in SSR" warning from React itself. I was partially successful in filtering out the "experimental" warning in tests as well.

But, from my perspective, it's a useless message cluttering up my terminal, much akin to the "hundreds of packages have audit issues warnings" you wrote about recently. It's irrelevant to my workflow, and it gets printed every time.

(On top of that, the particular "experimental" feature I just enabled is the externalDirs flag that was just suggested to me by Sokra specifically for my use case of importing files from other folders in the repo.)

[markerikson]

For the record, this is still totally an option I would like to have :)

I'm currently trying out the next/jest configuration, and it too is printing this "experimental" warning.

I know that. I'm okay with it. I turned it on. I don't need that message printing every time I run my test suites.

[leerob]

My initial feeling is to err on the side of caution and verbosity.

One benefit of the verbose console output is it helps the team understand what experimental features folks are currently opting into, which could explain why they're seeing breaking behavior. Without that, it requires another ask to see their next.config.js file to find out if they're turned off this logging.

Folks who are using experimental features are the early testers we're looking to provide feedback. I wonder if the root issue here is the particular experimental flag should be considered to be moved to the next stage (maybe still opt-in, not on by default) depending on its usage.

[PabloSzx]

I wonder if the root issue here is the particular experimental flag should be considered to be moved to the next stage (maybe still opt-in, not on by default) depending on its usage.

externalDir is essential for Next.js usage in monorepos, it would be great if that is the case

[switz]

One benefit of the verbose console output is it helps the team understand what experimental features folks are currently opting into, which could explain why they're seeing breaking behavior. Without that, it requires another ask to see their next.config.js file to find out if they're turned off this logging.

What if on the first startup message, there were "shortcodes" for experimental features:

ready - started server on 0.0.0.0:3000, url: http://localhost:3000, Experimental: ACDF

e.g. E = external dirs enabled

That might be pushing into "over-optimization" territory and over-complication, but I do agree suppressing these messages would be nice.

[balazsorban44]

As this seems to be more of a feature request, not an actual bug, I'll convert this to an Idea so the discussion can be continued there.

[lirbank]

These warnings also make CI fail since a non zero return code is sent. It would be awesome to be able to silent these.

[thinkjrs]

To disable you can comment away the body of the function experimentalWarning in the file node_modules/next/dist/server/config.js which is responsible for emitting the warning.

const experimentalWarning = (0, _utils).execOnce(() => {
  //Log.warn(_chalk.default.bold('You have enabled experimental feature(s).'));
  //Log.warn(`Experimental features are not covered by semver, and may cause unexpected or broken application behavior. ` + `Use them at your own risk.`);
  //console.warn();
})

[kenshanta]

but will this unblock the CI deployment? example netlify

[nicknotfun]

Just weighing in saying we'd also love this. We deploy our NextJS application and having each server spam with this log line is a bit silly to us; can we make it a custom hook or similar?

[jaggli]

We're logging with Datadog and needed to create a filter, but really shouldn't need to. If you want to force that stuff on users, please make it devmode only.

[Furmanus]

These warnings also make CI fail since a non zero return code is sent. It would be awesome to be able to silent these.

Any update on this? This is serious issue for me, I'm unable to deploy my application because of that.

[lvchenyang]

This feature is very helpful to me. Hope some one can pay attention to this issue!

[MariuzM]

13.4.19 and dont see any options to disable the warnings