Next.js: i18n with next export calls getStaticProps for each defined lang, but then errors

[sean256]

Bug report

Describe the bug

I'm attempting to use the brand new i18n feature for a static exported site. During build time it calls getStaticProps once for each lang defined in next.config.js and in some cases even builds the page, but at the end it fails with:

i18n support is not compatible with next export.

It feels like a tease having it _almost build_ lol.

To Reproduce

Add langs to config

module.exports = {
    i18n: {
        locales: ['en-US', 'fr', 'nl-NL'],
        defaultLocale: 'en-US',
    },
}

Add getStaticProps to a page, like /content.tsx

export async function getStaticProps(context) {
    console.log('getStaticProps', context); // context will include the `locale` for each lang defined
    return {
        props: {},
    };
}

Expected behavior

To either:

Export all lang paths
OR
Fail early until this is better supported for next export

System information

• OS: macOS
• Version of Next.js: 10.0.0
• Version of Node.js: 12.x

Additional context

Loaded env from /Users/REDACTED/gits/REDACTED/src/.env.production
info  - Using external babel configuration from /Users/REDACTED/gits/REDACTED/src/.babelrc
info  - Creating an optimized production build  
info  - Compiled successfully
info  - Collecting page data  
[   =] info  - Generating static pages (0/19){}
{}
{}
{}
[  ==] info  - Generating static pages (0/19)getStaticProps {
  locales: [ 'en-US', 'fr', 'nl-NL' ],
  locale: 'en-US',
  defaultLocale: 'en-US'
}
getStaticProps {
  locales: [ 'en-US', 'fr', 'nl-NL' ],
  locale: 'fr',
  defaultLocale: 'en-US'
}
getStaticProps {
  locales: [ 'en-US', 'fr', 'nl-NL' ],
  locale: 'nl-NL',
  defaultLocale: 'en-US'
}
{}
{}
{}
{}
info  - Generating static pages (19/19)
info  - Finalizing page optimization  

Page                                                           Size     First Load JS
┌ ○ /                                                          300 B           168 kB
├   /_app                                                      0 B             167 kB
├ ○ /404                                                       3.44 kB         171 kB
├ ● /content                                                   310 B           168 kB
├ ○ /foo                                                       300 B           168 kB
└ ○ /performance                                               297 B           168 kB
+ First Load JS shared by all                                  167 kB
  ├ chunks/d5fb258340a338fc09455890a68100a3d216cee4.6dfcc7.js  71 kB
  ├ chunks/f6078781a05fe1bcb0902d23dbbb2662c8d200b3.6547a9.js  11.4 kB
  ├ chunks/framework.a3ab6d.js                                 42.1 kB
  ├ chunks/main.fde44f.js                                      8.02 kB
  ├ chunks/pages/_app.6a0339.js                                34 kB
  ├ chunks/webpack.e06743.js                                   751 B
  └ css/afd7172b7cfc566ac23d.css                               20 B

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)
●  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)
   (ISR)     incremental static regeneration (uses revalidate in getStaticProps)

Loaded env from /Users/REDACTED/gits/REDACTED/src/.env.production
info  - using build directory: /Users/REDACTED/gits/REDACTED/src/.next
info  - Copying "static build" directory
info  - No "exportPathMap" found in "next.config.js". Generating map from "./pages"
Error: i18n support is not compatible with next export. See here for more info on deploying: https://nextjs.org/docs/deployment
    at exportApp (/Users/REDACTED/gits/REDACTED/src/node_modules/next/dist/export/index.js:14:296)

[ijjk]

Hi, as mentioned in the initial RFC next export wasn't planned for initial support. When doing a build we don't know that you're going to call next export so we can't show this error message earlier.

I'm going to close this since this is the expected behavior currently

[a14m]

@ijjk sorry I'm a bit confused, the documentation suggests that it's supported here: https://nextjs.org/docs/advanced-features/i18n-routing#how-does-this-work-with-static-generation (if I'm not mistaken)... but I run into the same issue running next export

[caribou-code]

I'm also very confused. Both the docs and RFC suggest SSG support for i18n, and the SSG functions seem to support it on the surface (exposing locale in the context params) but not during export. This looks like a valid bug to me.

[timneutkens]

It's supported in the hybrid approach which the majority of Next.js applications uses. We can investigate adding next export support for it for you under enterprise support, feel free to reach out to [email protected]

[a14m]

Will try to reach out, but it is definitely an important feature since we need to deploy static websites to client managed infrastructure (S3 or hosting provider, which usually cannot support the hybrid approach, they usually serve static files)

[caribou-code]

@timneutkens that's a shame. Is there any kind of roadmap/timeline for adding full SSG support for i18n (even if it's with language detection not supported)? Perhaps it's worth updating the documentation to reflect the current level of support, because it definitely looks like it's supported in the link above.

On a side note, I think this feature and the other new ones in Next.js 10 are totally awesome! Keep up the good work.

[a14m]

@caribou-code I did a quick investigation and it seems to be possible (but requires manual work, probably have to depend on a fork)...
first of all you can disable the error that raises in next export command, this can be done by commenting out this block:
https://github.com/vercel/next.js/blob/canary/packages/next/export/index.ts#L288-L292
(you can do that in the resulted file in node_modules too for testing (node_modules/next/dist/export/index.js -part of line 14-)

Then running yarn build and yarn export should work.
The last step is that you need to change the out directory content, the export command generates the configurations for every language in your locales configuration correctly, but you need to move the defaultLocale to be in the root directory (to imitate nextjs default behaviour)...
for example if your next.config.js have the following

  i18n: {
    locales: ["en", "de"],
    defaultLocale: "en",
  },

you need run the following commands

mv ./out/en.html ./out/index.html
mv ./out/en/*.html ./out/

then serving the out directory should work as expected

[timneutkens]

You're welcome to PR support for it to next export, however keep in mind it would have a bunch of edge cases, e.g. domains does not work, locale detection does not work etc.

[a14m]

yeah I know that there will probably be many edge cases... thanks for naming some

[kylekirkby]

I've just spent some time implementing this to only realise you can't use the next export command... why do the docs mislead us?

You can't tell me that doesn't suggest you can statically generate the i18n supported pages?