Hey there fellow SSTers, I've heard there was an update recently that helps you ignore some stacks when running local debug session. I've got static site deployment stack that is in dire need of being ignored but can't actually find the patch notes related... Any help will be appreciated

The update was to disable live development for functions. If you want to ignore a stack you can always put it behind an

if (!app.local)

Much appreciated!

Can you tell me a bit more about your setup and what you're looking to improve?

And they get deleted/recreted each time?

Hm the StaticSite construct should not be running builds during local development

Latest - yesterday's patch

if you run sst start then go to the url returned, what shows up there?

I'll look it up once more at home as I just got into the car

Gotcha, let me know. We have this code at the beginning of the function that builds the app

// Local development or skip build => stub asset
    if (isSstStart || skipBuild) {
      return [
        new s3Assets.Asset(this, "Asset", {
          path: path.resolve(__dirname, "../assets/StaticSite/stub"),
        }),
      ];
    }

Just to chime in real quick, on

sst start

,

StaticSite

shouldn’t build the web app. If the site was previously deployed using

sst deploy

, the first time u run

sst start

, the dummy site gets deployed, and that takes some time (CF invalidation). Re-running

sst start

will be fast.

Thanks @thdxr and @Frank! I can confirm that's the case, dummy page indeed shows up and consecutive starts are fast. I've been toying a bit with CustomResource lambda invocation recently and perhaps that fuzzies the time taken for whole debug startup

I see. Is the main motivation of the move to speed up

sst start

?

Indeed. Plus I sometimes plug in directly to the (deployed) uat env, instead of my own dev instance to hot-test the functions. With a tester meddling around and providing problematic requests it's easier to see what's happening directly on my machine. If sst were to put a stub page there then obviously this has to stop 🙂

@Lukasz K -I would be probably a bit careful with your usecase - for me one of the big points of being able to have on demand stack just built is not to actually try and use uat as a dev env - instead I rely on being able to quickly deploy something very similar to uat setup on a side - and debug it

@Tomasz Sobczyk thanks for the warning. I try to keep that to the minimum, in normal circumstances using my dev (deployed) env. Sometimes things just get out of hand when you've had to 'duct tape' external existing resources into a fresh, readable project... I'm in the process of migrating data, demolishing the entire legacy stack and building it in sst for ultimate control