sst / ion

❍ — a new engine for SST
https://ion.sst.dev
MIT License
1.09k stars 126 forks source link

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

Open dmeehan1968 opened 3 weeks ago

dmeehan1968 commented 3 weeks ago

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 https://github.com/sst/ion/commit/937c436a284c98c79000809bc447759f6c2401b1 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.

thdxr commented 2 weeks ago

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?

dmeehan1968 commented 2 weeks ago

@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.