Custom nextjs distdir is not respected

[troendheim]

In Nextjs it is possible to build to a customized path by setting a distDir in the next config

SST does not respect this setting and actively reads files in a hardcoded .next-folder as seen multiple times in platform/src/components/aws/nextjs.ts

The solution would be to check if that setting is set in the next.config.* and then find the route manifest etc. in the designated distDir instead of the hardcoded .next.

When this is done we're one step closer to be able to have the same Nextjs app deployed multiple times in the same sst.config.ts. Our use case is that we need to deploy the same app twice but a few different environment-variables. If they're ending up in the same distDir build artifacts will leak between them.

Related to opennextjs/opennextjs-aws#1100

[vimtor]

@troendheim what's the use case for this in the context of sst?

[troendheim]

@troendheim what's the use case for this in the context of sst?
In context of SST this would allow us to have the same nextjs-app deployed multiple times with different settings in the same sst.config.ts. Right now we've hacked around it and created multiple sst.config.ts files but that has the downside that we have to create secrets etc multiple times even though they're identical between the two.

The use case is:
We have a mono-repo with multiple nextjs apps:

• apps/catalog
• other apps

We want to deploy one of the nextjs apps (apps/catalog) multiple times with different settings; think different tailwind config, feature flags, different domains etc.

The iac could look like this:

new sst.aws.Nextjs("blue-catalog", {
        router: {
            path: "/",
            instance: router,
            domain: "x.com",
        },
        link: [...secrets],
        path: "./apps/catalog",
        environment: {
            PORT: "3000",
            THEME: "blue"
            ENABLE_ECOMMERCE: "true" // or whatever
            DIST_DIR: "./blue"
        },
)
new sst.aws.Nextjs("red-catalog", {
        router: {
            path: "/",
            instance: router,
            domain: "y.com",
        },
        link: [...secrets],
        path: "./apps/catalog",
        environment: {
            PORT: "3001",
            THEME: "red"
            ENABLE_ECOMMERCE: "false" // or whatever
            DIST_DIR: "./red"
        },
)
// ... the other apps

And then in the next.config.js we can set the distDir to be that of process.env.DIST_DIR
Next supports building the same app/path concurrently as long as distDir is configured because it'll then build to ./red and ./blue.
As it stands now: if a person sets the distDir setting in nextjs, SST build will fail because it looks for route manifest etc in a hardcoded path (.next)

[vimtor]

i'm afraid you we will need upstream support from open next to properly fix this

in the meantime you might want to try something like:

const site1 = new sst.aws.Nextjs("blue-catalog", {
        router: {
            path: "/",
            instance: router,
            domain: "x.com",
        },
        link: [...secrets],
        path: "./apps/catalog",
        environment: {
            PORT: "3000",
            THEME: "blue"
            ENABLE_ECOMMERCE: "true" // or whatever
            DIST_DIR: "./blue"
        },
)
new sst.aws.Nextjs("red-catalog", {
        router: {
            path: "/",
            instance: router,
            domain: "y.com",
        },
        buildCommand: `rm -rf .next && npx —yes open-next@OPEN_NEXT_VERSION build`
        link: [...secrets],
        path: "./apps/catalog",
        environment: {
            PORT: "3001",
            THEME: "red"
            ENABLE_ECOMMERCE: "false" // or whatever
            DIST_DIR: "./red"
        },
        { dependsOn: [site1] }
)

haven't tested this but it probably works

[troendheim]

@vimtor that's a pretty hacky workaround which also breaks the possibility to build apps in parallel, although I agree it might work.

What I explained earlier was just our reason to want to use a custom nextjs distDir but there could easily be others. If the users have that configured they cannot use with SST. I think that alone should be reason enough to consider solving it, regardless of use case. This is an undocumented incompatibility.

[mss-dieliko]

I'm also experiencing the same issue when I'm deploying multiple NextJs Sites with the same code base but with different NextJs configurations using a for loop.

It's likely because of that SST is continuing too fast to the next NextJs site deployment and thereby open-next cleans up the outputDir too early. This even occurs when I add the dependsOn of the previous site. The open-next build is completed but it seems that SST still needs to update (and depends on resources from the .open-next folder) the some AWS resources.

I tested with applying a timeout of 10 seconds, I know not the best way XD, just before the opennextjs/aws buildHelper.initOutputdir to prevent the cleanup. That seemed to work.

So for now I'm using a Semaphore and use $util.all to wait on the NextJs site to be completed and then apply a 10 seconds timeout before releasing the semaphore.

Example:

let previousNextjs: sst.aws.Nextjs | undefined;
const limiter = new Semaphore(1);

return nextJSSites.map(async (site) => {
  console.log(`---------------- Acquire Semaphore for NextJs Site ${site} ----------------`);
  await limiter.acquire(site);

  const nextJsSite = new sst.aws.Nextjs(site, {
    ... nextjs site config here
  },
  previousNextJs ? { dependsOn: [previousNextJs] } : undefined,
  );
  previousNextjs = nextJsSite;

  return $util
      .all([
        nextJsSite.url,
        nextJsSite.nodes.server,
        nextJsSite.nodes.assets,
        nextJsSite.nodes.cdn,
        nextJsSite.nodes.revalidationFunction,
        nextJsSite.nodes.revalidationTable,
        nextJsSite.nodes.revalidationQueue,
      ])
      .apply(async (_) => {
        console.log(`---------------- NextJS deployment ready for NextJs Site ${site} ----------------`);
        console.log(`---------------- Waiting for 10 seconds to continue ----------------`);
        await timeout(10000); // Add delay to ensure AWS resources are fully available before next deployment
        console.log(`---------------- Releasing Semaphore for NextJs Site ${site} ----------------`);
        limiter.release();
        return nextJsSite;
      });
});

[mss-dieliko]

@vimtor can you perhaps make an estimation if this multi nextjs site deployment use case is something sst related or an opennext related issue when you look at ?