next export breaks on i18n even when disabled
Verify canary release
- [X] I verified that the issue exists in the latest Next.js canary release
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 21.6.0: Sat Jun 18 17:07:22 PDT 2022; root:xnu-8020.140.41~1/RELEASE_ARM64_T6000 Binaries: Node: 16.13.0 npm: 8.5.0 Yarn: 1.23.0-20220118.1001 pnpm: N/A Relevant packages: next: 12.2.4-canary.9 eslint-config-next: 12.1.6 react: 18.2.0 react-dom: 18.2.0
What browser are you using? (if relevant)
n/a
How are you deploying your application? (if relevant)
n/a
Describe the Bug
As described in #18617 & #18482, next export breaks, even when i18n is disabled as described in the docs.
The root cause may be i18n config appears to be broken. Specifically, if you use the config described in the docs:
// next.config.js
module.exports = {
i18n: {
localeDetection: false,
},
}
...you get the following error:
Error: Specified i18n.locales should be an Array received undefined.
If you read the error & attempt to address it by adding locales: ['en-US'], to the i18n config object, you get the following error:
Error: Specified i18n.defaultLocale should be a string.
If you read the error & attempt to address it by adding defaultLocale: 'en-US', to the i18n config object, you get the following error:
Error: i18n support is not compatible with next export. See here for more info on deploying: https://nextjs.org/docs/deployment
The entire reason I'm trying to disable i18n is to succeed in using next export as prompted by that exact documentation link.
Since this underlying issue has been documented in #18617 & #18482, I think this is a regression.
Expected Behavior
I should be able to run next export without it crashing (exit code 1). Additionally, if the solution is to disable i18n, the instructions to do so should work as documented.
Link to reproduction
https://stackblitz.com/edit/vercel-next-js-hjzwyk?file=next.config.js
To Reproduce
open terminal and run yarn export, which will yield the following error:
> Build error occurred
Error: Specified i18n.locales should be an Array received undefined.
See more info here: https://nextjs.org/docs/messages/invalid-i18n-config
If you update the i18n config to this:
i18n: {
locales: ['en-US'],
defaultLocale: 'en-US',
localeDetection: false,
},
...and re-run yarn export, you get the following error:
Error: i18n support is not compatible with next export. See here for more info on deploying: https://nextjs.org/docs/deployment
Probably because Static HTML Export doesn't support Internationalized Routing
You can see that in Unsupported Features in Static HTML Export
Probably because Static HTML Export doesn't support
Internationalized RoutingYou can see that in Unsupported Features in Static HTML Export
Hi @Babbili that's the entire reason I'm trying to turn off internationalized routing, which is the point of "Disabling Automatic Locale Detection".
I read through the entire documentation for both Static HTML Export, as well as Unsupported Features in Static HTML Export and i18n Routing, and this is the only setting that jumped out as the most obvious way to disable internationalized routing, so it won't run afoul of this specific Static HTML Export limitation. If there's a different set of settings I need to use in order to successfully disable Internationalized Routing, then it is not at all obvious from the documentation.
More likely, the documented method to disable Internationalized Routing is not functioning as advertised, which is a bug (one that's happened multiple times before).
In the alternative, if it works as advertised but a completely undocumented technique is needed for what I'm trying to accomplish, then this seems a glaring gap in the documentation.
I think you don't need to turn internationalized routing off since it's turned off by default. So you can just remove all i18n settings in your next.config.js and you should be able to export successfully. As you can see in the basic export example there is no next.config.js at all.
Hi @alex289, that's great news! However, there are still legitimate reasons why I might want to explicitly turn this off, which is the entire reason it exists in the docs. And using the setting -- precisely as described in the docs -- should not break nextjs, as demonstrated in the linked reproduction. That does not stop this from being a bug.
The rule of thumb for config settings (and docs) should be "first, do no harm". If the default is the internationalization is turned off, then telling nextjs explicitly to turn it off should not cause an error. It should simply ignore the setting and let me move along on my merry way.
If a plugin turns internationalization on, then I should be able to explicitly turn it off in this config and override those settings. This is by design, not by accident.
I agree. The docs should be more precise on this and next should maybe give a warning for this kind of invalid next.config if this is not intended.