next export with getServerSideProps

[eric-burel]

Feature request

Is your feature request related to a problem? Please describe.

Why using both next export and getServerSideProps

I develop apps that may be deployed on premise. For the same codebase, I'd like to leverage as many deployment options as possible.

• next export is the simplest of them. The interesting part is that it doesn't depend on Node, or on the build environment: I can deliver it as is to a client that don't have the ability to install Node.js on its server/dev machine.It does happen more than one can think, even in 2020 especially in big/old companies where introducing a new technology is a complicated process, or that do not use SaaS applications at this point.

• "normal" deployment with a Node server and SSR, for other companies

I may need to deploy the same app on dozens of companies, I really do need to keep a "no dependency to Node" strategy around.

Edit: other relevant use cases:

• You can't control 3rd party libraries. Some of them might use getServerSideProps for some optional feature, and thus break your export. So even if you just want next export, without ever using getServerSideProps, you may have some trouble
• You may have difficulties with SSR: handling a refresh token with SSR is still an open subject: Allow Intercept getServerSideProps #17515. Having to support SSR may hinder your development capabilities at early stage of a project. You might still want to have a SSR, but wait a bit later when it's really useful in your app and worth the hassle.

Problem

next export will just fail if a page is using getServerSideProps.

Limitations

I am aware that next export is a a secondary feature. However, when you use it for an app, you do use it and it become a very important part of the deployment process.

I am also aware that supporting next export and getServerSideProps altogether would definitely create confusion for end user. Mostly because static export seems to be confused with Next's build-time server-side rendering+incremental refresh, so people forget that they don't have a server in this scenario.

Of course, for this to work, you need your getServerSideProps function to be optional. It should either be limited to a performance boost (eg caching stuff in Apollo, redirecting quickly), or "duplicated" in the client code when it doesn't run.

Describe the solution you'd like

Possibles solutions, in order of preference:

• Don't throw an error, just a big warning, when exporting pages with getServerSideProps. And of course ignore the function itself.
  We already ignore API routes during next export so we could ignore getServerSideProps too

• Don't deprecate getInitialProps, instead consider it as advanced feature that can be used to handle multiple scenarios in the same page, and maybe improve it to make it easier to differentiate the current rendering scenario (client, server, static export). Currently you have to reach the old documentation to get it, and play around with context req to guess the current environment.

• Add an option to allow exporting a page that include getServerSideProps, eg allowStaticExport, optionalGetServerSideProps, makeSureThatYourPageWorkWithoutGetServerSidePropsToo, whatever

• Create a new callback, getIsomorphicProps, that should work both client-side and server-side (unrealistic, because you wouldn't be able to use React hook, or access the server request, so you wouldn't be able to code smth clean, but you get the idea)

• Create a new callback, getPrecomputedServerSideProps, that is explicitely meant to be optional

Describe alternatives you've considered

Using getInitialProps is a palliative, see our withPrivateAccess HOC that supports all scenarios.

Other possible alternative proposed by @jescalan: create a Babel plugin/script that removes getServerSideProps from the code and imported modules, and tweak export command like so "export": "node ./scripts/remove-server-props.js && next export.
But again IMO if export doesn't fail when there are API routes in the code it probably should'n't fail when there are getServerSideProps in a page.

Additional context

The apps I develop are almost softwares, so few pages, but high complexity on each page. SSR is cool when you host yourself, but static export is also cool in this scenario, especially when you host on-premise as it is almost similar to an executable you can reuse on any machine.
I can't predict which deployment scenario will be used at the time I write the code, I often get the info mid-project.

Also, I use Apollo massively. It's a good fit for this multi-target export scenario: server-side, you can prefill the cache by running queries. But client-side, Apollo is also able to rerun the query if it failed during server-render or was never run in the first place (basically when it encounter a cache miss).

Eventually, when running Cypress tests, you can't mock server side rendering calls. Since SSR can't be disabled on the fly, one possible path is to use next export when your app supports it alongside SSR.

Related discussions

• Next export and getServerSideProps risk of confusion pages with getServerSideProps cannot be exported #15440
• Private pages in all scenarios Private pages in Next, even when you don't have a server #49 #14531 https://stackoverflow.com/questions/58173809/next-js-redirect-from-to-another-page/60616536#60616536
• No possibility to disable SSR Provide a mechanizm to disable SSR #4381
• This leads to Next export not being supported in next-18nnext. Serverless or next export, you have to pick one if you want i18n Next export is broken with v6.0.0 i18next/next-i18next#780

[eric-burel]

I've published a draftish, unsafe, untested Babel plugin that could help removing getServerSideProps during next export:

• https://github.com/lbke/babel-plugin-next-optional-server
• https://www.npmjs.com/package/babel-plugin-next-optional-server Edit: see @erzr comment below for a better plugin

Still not sure where to put it so it is triggered during export, but unit test are ok.

The idea would be to use https://github.com/hashicorp/prebuild-webpack-plugin before calling <prebuild step> && next export instead of just next export alone

[eric-burel]

I am not very satisfied with the Babel approach after more digging. First it is difficult to setup, I've tried to use PrebuildPlugin to run a prebuild step but I still can't tell how to apply a babel plugin programmatically to the files. Then it is costly in terms of performance.

And I still can't consider relying on next export safe as long as the mere presence to getServerSideProps in a 3rd party package makes the whole thing explode (without even talking of having multiple deployment mode for the same app).

So the cleanest way to handle this would be to add an option to next export for this advanced use case.

Digging into Next code, the following steps would be needed:

• in packages/next/export/worker.ts do not throw error when getServerSideProps is found.
• then, calling getServerSideProps during render should be disabled. It is related in packages/next/next-server/server/render.tsx

Example:

    if (!isForcedExport && getServerSideProps) {
      props[SERVER_PROPS_ID] = true
    }

    if (!isForcedExport && getServerSideProps && !isFallback) {
      let data: UnwrapPromise<ReturnType<GetServerSideProps>>

isForcedExport should be true when calling next export --allow-getServerSideProps for example. According to the code, renderOpts.nextExport seems to be the boolean that handles this, but there are a lot of different scenarios ongoing and it seems to be mutated in certain case like when you have getStaticProps in your page.

Regarding getStaticProps vs getServerSideProps

• There is also another subject: getStaticProps and getServerSideProps are not supposed to be used along, on the same page. But if you want to export, it means that you most probably use getStaticProps to fetch data. So we should also disable the error that happens when you define both methods in this scenario.

More broadly, I think it is also weird that getStaticProps and getServerSideProps cannot be used together. You will get You can not use getStaticProps or getStaticPaths with getServerSideProps. To use SSG, please remove getServerSideProps if you sue both.
So if you want to fetch both build time and request time data, you have to use getServerSideProps. So you end up using getServerSideProps... to fetch static props. It can quickly become confusing.

Edit: getStaticProps seems to be targeted at static render exclusively, so you end up with HTML and thus can't call getServerSideProps later on. You may indeed want to use getServerSideProps in any other scenario including to fetch your static, public data.

[craigatproperly]

Wanted to add another +1 to this as a useful scenario. Specifically for the case of the same code base being deployed in different ways. In our scenario it seems allowing the presence of getServerSideProps in the codebase when exporting (but of course leaving it inactive in that scenario) would achieve our desired results.

We are investigating work arounds of splitting our codebase differently; and generally trying to determine how to have those exports conditionally present in different deploy scenarios.

Update on workaround for the "same codebase deploy as ssr or ssg":

Works at the unit level, still testing end to end:

1. Added webpack-preprocessor-loader
2. configured next.config.js to extend with webpack plugin configured like :

module.exports =  {
  webpack: (config, { defaultLoaders }) => {
    const preprocessLoader = {
      test: /\.js$/,
      use: [
        {
          loader: 'webpack-preprocessor-loader',
          options: {
            params: {
              EXPORTS_FOR_BUILD: 'SSR', // or "SSG", to be set via environment variables.
            },
          },
        },
      ],
    };
    config.module.rules.push(preprocessLoader);
    return config;
  },
};

3. Defined the exports on the pages per the preprocessor:

...
const getServerSideProps = ()=>{ /*server props implementation*/ } 
...

// #!if EXPORTS_FOR_BUILD === "SSG"
export {getStaticProps, getStaticPaths};
// #!endif

// #!if EXPORTS_FOR_BUILD === "SSR"
export { getServerSideProps };
// #!endif

[eric-burel]

Note that you may want to check what is bundled into the client export in this scenario, because as far as I understand, Next has some custom logic to remove server-related code from the client bundle when encountering getServerSideProps.
So I wonder if your solution will remove it after the code is "sanitized" for client bundle (in which case it's fine), or before.

[erzr]

I put together a little babel plugin to help address this issue: https://github.com/erzr/next-babel-conditional-ssg-ssr

[mlynch]

Wanted to add some more weight to this. One usecase for having a better fallback option so you can use getServerSideProps and next export is the case of a universal web/PWA and native mobile app.

For the PWA, you may want routes to be server-side rendered. However, if you then deploy that same code to iOS/Android using something like Capacitor, then you'd be doing an export and will be handling data fetching/etc. client-side.

Having both in the code base is actually fairly natural, since those routes won't ever even fire when running in this case because all navigation is done client-side, but data fetching/etc. can be done using the exact same code in many cases (if making API calls rather than doing node operations)

Going to check out some of these babel plugins, thanks @erzr!

[seanaguinaga]

@mlynch did you make any discoveries regarding getServerSideProps and next export?

[antonioberetini]

We are also waiting on a viable solution. Our team is looking to leverage Capacitor with Next.js. Unfortunately, as of now we cannot generate static pages due to complexities in routing we were required to implement for our business model - The fallback: true mode of getStaticPaths is not supported when using next export.

[CyberCyclone]

I'm looking into this as well. Seems like year without a viable option means that Next.js isn't too friendly with mobile apps. It's hard fining a good framework that supports mobile and web.

[vadistic]

Hey, just posting my workaround for mixing ssg and ssr routes with static export.

After checking out other proposed solutions - I just ended up creating two separate directories src/pages-ssr & src/pages-ssg and hard linking those files to src/pages depending on build type.

Not pretty but fortunately not a blocker 🤷. And have an advantage of not having to hack webpack/babel - which is hard eg because of this: afterwind-io/preprocessor-loader#16

Btw. symlinks/links on directory & symlinks on files did not work. But hard links on files do.

// scripts/link.ts

#!/usr/bin/node

import arg from 'arg'
import fs from 'fs-extra'
import glob from 'globby'

export type LinkOptions = {
  mode: 'ssr' | 'ssg'
}

// this just switches between ssg and ssr version of the app pages.
// but you can also rewrite it to link both for ssr and opnly sgg for ssg.
// or use filenames like `page.ssr.ts` naming from single directory, filter it, and rename it during linking

export async function linkPages({ mode }: LinkOptions) {
  const source = `src/pages-${mode}`
  const target = `src/pages`

  await fs.emptyDir(target)

  const paths = await glob(source, { absolute: false, fs })

  await Promise.all(paths.map(path => fs.ensureLink(path, path.replace(source, target))))

  console.log(`Linked pages from ${source} to ${target}.`)
}

// run as cli script if this directory was called
if (require.main?.filename === __filename) {
  const { '--mode': mode } = arg({
    '--mode': String,
  })

  if (!mode) {
    throw new Error(`--mode is required`)
  }

  if (mode !== 'ssr' && mode !== 'ssg') {
    throw new Error(`--mode should be ssr or ssg`)
  }

  linkPages({ mode })
}

To handle caching correctly (I have this issue also with webpack-preprocessor-loader & custom babel plugin solution) I use two separate dist directories eg. .next-ssg & .next-ssr.

// next.config.js
module.exports = {
  distDir: process.env.DIST_DIR
}

And simple usage can be like:

# build ssr
DIST_BUILD=.next-ssr
ts-node -T scripts/link --mode ssr
next build

# build & export sss
DIST_BUILD=.next-ssg
ts-node -T scripts/link --mode ssg
next build
next export

[exromany]

I found a way to export an application that has getServerSideProps, which does not require changing the configuration of babel, webpack, or replacing files. It turned out that export const getServerSideProps = undefined; does not give errors when exporting. That is, you can do this:

export const getServerSideProps = process.env.SKIP_SSR ? undefined : myFunctionToGetProps;

But this is still a hack that requires a separate build of the project.

SKIP_SSR=1 next build && next export

[eric-burel]

Almost sure you leak server-side code into your client bundle with this

[exromany]

nope, tree-shaking works well

[eric-burel]

Then that's great! It could be used as Babel plugin or similar that adds the "process.env.SKIP_SSR ? undefined :" part automatically before Next starts analyzing the code itself.

[vadistic]

Hey, the issue is that my static export require getServerSideProps which throw validation error when mixed with getStaticProps, even if one of those is undefined.

import type { GetServerSideProps } from 'next'

import type { PostData } from '../page/post'
import { Post } from '../page/post'

export default Post

export const getServerSideProps: GetServerSideProps<PostData> = async context => {
  return {
    props: context.query as any,
  }
}

export const getStaticProps = undefined

Error: You can not use getStaticProps or getStaticPaths with getServerSideProps. To use SSG, please remove getServerSideProps

which I think warrant at least small update to allow such scenario.

[ivan-kleshnin]

Given that exportPathMap is incompatible with dynamic SSG the above approach seems to be the only one that kinda works.

Yet there's a problem: the pages with (disabled) getServerSideProps will still be exported as static pages, polluting the out folder and potentially messing things up.

To clean them up, another build step is necessary. At which we conditionally remove "incorrect" pages based on build artefacts / manifest files. Formats of those files are not a part of the public API and might be changed at any moment – breaking our build pipelines.

Yet another problem is that rewrites are not compatible with export #24627

It seems that we require an upgrade to NextJS (like new export command or a new alternative to it) to fix all that.

[CameronCT]

With Capacitor your app has to be built out using next export which throws the no SSR error.

After doing some digging I found out that using getInitialProps still works with next export which is an interesting case since it's naturally SSR.

The goal I have is so when I generate the native version of the app, it will contain the beauties of SSR with the possibility of SEO (especially for Open Graph social cards) but allow the app to be used the same on mobile and when/if a user wants to share a link it will still show a Social card upon sharing.

I've looked into the pitfalls of getInitialProps and it states that Static generation is not possible, but it is usable on separate pages (which is good) and the only "negative" use I see for it is that it's likely going into the deprecation stage sooner or later.

[balazsotakomaiya]

Thanks mate, this seems like a decent tradeoff for the time being.