Provide mechanism to disable or override preview mode keys

[Gaelan]

Feature request

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

My app doesn't currently use preview mode. However, every time I run next build, I get a new version of the app with different preview keys, needlessly slowing down my deployments.

Describe the solution you'd like

Provide a mechanism to either a) disable preview mode or b) provide the preview mode keys myself (perhaps something analogous to generateBuildId), so the output of next build doesn't change unless my code does.

Describe alternatives you've considered

I could just deal with updating every page, even if I'm deploying something unrelated. It's a bit annoying, but ultimately not a big deal.

[Timer]

Could you elaborate a bit more? Having Preview Mode doesn't slow down your deployments.

[Gaelan]

Sure. My deployment mechanism hashes files to determine whether they need to be re-deployed. Using serverless mode, Next 9.5, Webpack 5, and a generateBuildId that returns the git commit hash, running next build twice in a row still changes every file in .next/serverless/pages, because it generates a new previewModeId, previewModeSigningKey, and previewModeEncryptionKey. Without that feature, my deployments would only need to upload the code for pages that actually changed, which would speed things up a fair bit.

[Timer]

Ooh interesting! We could probably explore extracting this information into environment variables instead of inlined into the file. Since this is so low-level and an implementation detail, we likely won't be exploring adding a way to omit this from the output—it's not worth increasing the API surface.

[acburdine]

I've got a similar issue with the preview build keys using a hashed deployment system. To workaround for the moment (I also don't use preview mode) I'm just wrapping the next build process and overwriting the keys in the various files they appear in to hardcoded constant values. Would definitely be interested in an alternative approach to what I'm currently doing - would also be interested in contributing a solution to said problem if it would be accepted 😄

[douglasduteil]

Same issue.
I also don't use preview mode.
I overwrite the keys by mocking the randomBytes

// next.config.js
require("crypto").randomBytes = () => "FIXED_PREVIEW_MODE_ID";

module.exports = {
  target: "serverless",
  generateBuildId: () => process.env.BUILD_ID || "build",
};

$ yarn next build 
[...]
$ find .next -not -path "*/cache/*" -type f | xargs sha1sum | sha1sum
a51a886da356988b317546ca4beccc8d0ba7d2c8  -
$ yarn next build 
[...]
$ find .next -not -path "*/cache/*" -type f | xargs sha1sum | sha1sum
a51a886da356988b317546ca4beccc8d0ba7d2c8  -

[lsfgrd]

I came across this discussion while trying to find a Preview Mode solution for an application that has multi zones.

It turns out that by not having an option like the one suggested by the OP, the Preview Mode becomes inviable on my application, because for each zone Next.js generates a different previewModeId and this condition exists. It means that if I set the preview mode cookies in zone A, if I access any route on zone B those cookies are deleted because zone B has a different previewModeId (according to the linked if condition).

If I had something similar to generateBuildId but for the previewModeId I could solve this issue. The reasoning for this is pretty much the same as pointed in the documentation for the build id:

This can cause problems in multi-server deployments when next build is ran on every server. In order to keep a static build id between builds you can provide your own build id.
– Configuring the Build ID

Sadly didn't find a workaround. @douglasduteil solution doesn't work for me, I can't just override the randomBytes function from crypto since other things will break if I do that.

[diroussel]

I have the same problem too. It seems to be the preview mode ids that stop us getting a deterministic build. We used to be able to get a deterministic build before this preview mode was added.

[diroussel]

This seems a better way to override the randomBytes() function at build time. It's based on @douglasduteil 's approach, but actually gives valid outputs. I base the random number seed on the $CI_COMMIT_SHA, but may others would want a different seed. @lsfgrd maybe this works for you?

// next.config.js
const DeterministicPseudorandombytes = require('deterministic-pseudorandombytes');

// override to fix non-deterministic build issue, see https://github.com/vercel/next.js/issues/15609
const prnd = new DeterministicPseudorandombytes({
  seed: process.env.CI_COMMIT_SHA || 'test_build_id',
});
require('crypto').randomBytes = prnd.randomBytes.bind(prnd);

[jams2]

Inconsistent preview mode IDs between Next.js instances is an issue for our use of preview mode. In our scenario (headless CMS), a different Next.js instance to the one that set that preview mode cookies may handle the subsequent request (i.e. the request to serve the actual preview), in which case decoding of the cookies fails and we are unable to process the request. This seems to be the same issue that @lsfgrd has described.