i18n with next export calls getStaticProps for each defined lang, but then errors

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

[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 [e-mail]