How can I use a single build for different environments but keep the benefits of static generation (or ISR)?

[michaelschufi]

We are using a separated build and release pipeline in our CI/CD process. This has the major benefit of having to do only a single build, which then can be deployed to different environments we like. Each of those environments have of course, different environment variables.

However, using Next.js we cannot make use of the performance improvements static generation provides, since we would have to create a build for each environment separately, just because we have to turn off a flag or want a few variables changed.

I was very excited when I first heard about Incremental Static Regeneration. It sounded very nice and I thought we would have a way to statically generate the pages at runtime once, using runtime variables, and they only have to be rerendered by the server if some content changes.

Is there any way to use a single build for different environments, with different runtime variables, and not use getInitialProps?

[rajmasha]

@michaelschufi Were you able to figure out a solution for this?

[michaelschufi]

Hi Raj

We are using dynamic routes like [[...slugs]].tsx or [slug].tsx together with fallback: 'blocking' in getStaticPaths. This makes Next.js not build those pages at build time (500 error page excluded, ofc). fallback: 'blocking' makes the pages render in an SSR-like context for the first visit, but subsequent visits follow the ISR stale-while-revalidate pattern.

I hope that helps. :)

[rajmasha]

@michaelschufi Thanks for taking the time to share this.

[pascavi]

Hi @michaelschufi

We had the same problem. As we are using Incremental Static Regeneration dynamic pages were not a problem, we were using blocking strategy and that skipped the build for them. However for non static routes such as the page index.js there is not a native solution, we had to add a node script removing the statically generated html and json files before creating the CI artifact.

[pascavi]

Hi Michael,
Dynamic routes such as, for example, news/[news_id].js have the option of using getStaticPaths to decide what pages should be built during the build process. If your build is meant to be deployed in different environments you may want avoid any of these pages to be built, because content could be different.
However if you have a page with no parameters in the route, something like news.js when you use getStaticProps you don't have any option in NextJS to exclude that page from the build process. The content of this static page may not be suitable for the different environments where you need to deploy the build.
The only solution I could find was deleting news.html and news.json (in this example) from the build using a script. Then NextJS generates the page again the first time is visited.

I really think NextJS should provide an option in getStaticProps to exclude the page from being rendered during the build process.

[michaelschufi]

However if you have a page with no parameters in the route, something like news.js when you use getStaticProps you don't have any option in NextJS to exclude that page from the build process. The content of this static page may not be suitable for the different environments where you need to deploy the build.

I see. I generally avoid using no parameter routes at all when I need to support multiple environments. All you need to do is handle the routing yourself in that case, which is quite straightforward since you can just look at the param in the context and check if it's whitelisted, returning {notFound: true}, if the path/page isn't available.

I agree with you, that it would be great to have the option directly, since my described method is defeating the purpose of file system routing.

[mAAdhaTTah]

If you return an empty array from getStaticPaths, no pages will be built at build-time & setting fallback: true or blocking will ensure it hits the getStaticProps, where you can return either the data or notFound: true appropriately. We're doing this because we're dealing with the same problem and it works well enough.

[pascavi]

Unfortunately custom routing is not an option if you want to keep NextJS in place for navigation without page reload. Or at least we found complex to implement a custom routing using that FE react router

[mAAdhaTTah]

It's not really "custom" – it's taking advantage of Nextjs's routing, so it should still work for client-side transitions. We're doing it this way without issue right now.

[IvanKuzyshyn]

Is there any update on this topic, maybe something has changed with the release of Next.js 14?

[mickaeltr]

I'm following this discussion, hoping that this will be possible someday: #46544