0.0.404 "Simplify type generation" breaks types for Nextjs installed in a sub-path

[Dave Meehan]

I have a Nextjs app which is in a subpath of the SST root directory, so my config looks like:

 new sst.aws.Nextjs('Dashboard', {
      path: 'packages/dashboard',
      // etc
})

In previous versions, packages/dashboard/sst-env.d.ts was generated and contained any resources from the config.

The code now generates the following in packages/dashboard/sst-env.d.ts:

/* tslint:disable */
/* eslint-disable */
/// <reference path="../../sst-env.d.ts" />

And places the actual definitions in <root>/sst-env.d.ts:

/* tslint:disable */
/* eslint-disable */
import "sst"
declare module "sst" {
  export interface Resource {
    Dashboard: {
      type: "sst.aws.Nextjs"
      url: string
    }
    PanelSettings: {
      name: string
      type: "sst.aws.Dynamo"
    }
  }
}
export {}

Essentially the change in 937c436 has relocated the type definitions to the root, but the linkage appears to be insufficient for the build step to find.

After upgrading, the deploy worked on the first attempt, I think because it was referencing the previous sst-env.d.ts output, and then on subsequent deploys the build failed as the members of Resource no longer existed (from the compilers perspective).

NB: If downgrading to an earlier version of sst CLI, its necessary to attempt to deploy more than once before it'll pick up the new definition.

I suspect the reason for the multiple deploys is because sst-env.d.ts in either location isn't written until after the build step, so it can be one iteration behind when building (or maybe there is some other caching going on).

NB: It doesn't matter whether I run the deploy from the project root or the subpath directory (I am usually in the habit of running it from the subpath, but have tried both ways to see if that's a factor). The relative path in the reference directive is correct when viewed from the perspective of the subpath where the NextJS project is located, but I suspect this might then be running with the project root as the CWD so its no longer correct. As the file is regenerated on each deploy, I can't simply edit it as a workaround.

[Dax]

i'm having a bit of a hard time following - can you summarize what the exact issue you're having on the latest version of sst?

and can you narrow it down to just deploying from the root?

[Dave Meehan]

@thdxr when a nextjs project is in a subpath from the sst root, the linkage from sst-env.d.ts to the root breaks the nextjs build step. This didn’t occur in previous versions as the sst-env.d.ts contained the Resource declaration without relying on a link.

It doesn’t matter if the deploy is run from the root or the subpath, the build step fails.

[Dave Meehan]

This is still a problem in 0.0.535.

I'm unable to deploy my next app because it can't resolve Resource references.

What I'm finding odd here is that sst dev works, but is using the same sst-env.d.ts generated files, but the sst deploy then encounters a problem.

I've figured out a workaround, which is to use the SST_RESOURCE_* environment variable in the script, instead of the Resource import.

const TABLE_NAME = JSON.parse(process.env.SST_RESOURCE_PanelSettings ?? '{}').name

My thinking is that this is a difference between how the build is achieved for dev and deploy modes, and that next is not honoring the <reference path=...> tag when in deploy mode, and so it fails type validation. I've tried nest build --no-lint and its not the linter that fails, but some of the step of the next build that does type validation.

One could use ignoreBuildErrors (not tested) in the next.config.ts file but this doesn't seem to be a viable route.

[Jay]

Can we get a repo to reproduce this?

[Dave Meehan]

@jayair

Repo: https://github.com/dmeehan1968/sst-issue-530

See the commit messages (multiline) which outline the steps taken to create.

Notes:

1. /sst-env.d.ts has generated references to the secret and nextjs resources
2. /packages/dashboard/sst-env.d.ts has a relative reference to the root sst-env.d.ts
3. Look in /packages/dashboard/src/app/page.tsx where there is a Resource import and attempt to use the secret value
4. I tried this with the placeholder value and after setting a value for the secret
5. My IDE (Jetbrains PHPStorm) says it can't find module 'sst' (this does work in my original project)
6. Unable to reference Resource.MySecret due to missing 'sst', but in my original project Resource is found but there are no known properties.