@thdxr :

Right now sst.json needs to be at the root of your repo

We have some tricky situations to deal with to support it being a subpackage

I appear to have this working (

sst.json

in subpackage), and am planning on adding a second SST app to this monorepo...can you help me determine why this won't work, or if I have found a path? Is it specifically related to

start

? or would it also affect

build

and

deploy

?

Wait what? When was that quote from? I'm using two SST apps in a monorepo as of SST v0.57.0. Is this a new 0.59.x issue?

Thanks Derek. Hmm. Is that only a hot reload problem? I don't use that. 🤞 (TDD!)

ha! nice. that hot reload across symbolic links is likely to be a problem regardless of monorepo or just using

npm link

.

I'm still on v0.57.0. Only used start once to see what it does, but test via unit tests, not manual live debugging.

be nice to have the option, but im with you on primary vs troubleshooting

🤷 I find SST's "stage" option and constructs just makes serverless application development easier than straight CDK. But yes, should I ever need live debugging I'm sure I'll find it to be awesome. 😄

well, it will be interesting to hear what Dax has to say, i am hoping monorepo isnt going to cause tons of problems

@Derek Kershner when did you setup your project?

this past week

ah ok - I did a big refactor of a lot of things in 0.56.0 and I knew they implicitly fixed some of the issues but hadn't got around to fully assessing if subpackages work now so I didn't want to recommend it

ok, ill continue down the path, and ill let you know if I run into anything. so far the issues have all been similar to ones in a normal repo, or self-imposed.

Sorry for the confusion!

each piece of this monorepo is simple, but there are probably gonna be 7 pieces, including 2 SST and 1 CDK.

Actually one more question, does your stacks code reference any lambda functions above sst.json?

no, I treat each piece of the monorepo as a repo (no knowledge of anything above it)

Ah ok that was never an issue, the issue was with the following:

/
  /sst
    stacks/
    sst.json
  /lambdas
    function.ts

And people doing

handler: "../lambdas/function.handler"

Ah, yeah Typescript generally has trouble with that kind of structure.

If the package is in a workspace, do workspace dependencies also trigger recompile and hot reload? Tend to use yarn workspaces v1 and typescript references to do this. Curious, because I would adopt what @Derek Kershner has done and have SST apps be on the leaf nodes of my monorepo, rather than at the root. Likewise I think, having relative path above the sst.json relative folder seems incorrect. How does this work for example if a workspace had a folder full of custom constructs, would the advice be to make that a package and pull it in using workspaces tooling?

I don't think things in

node_modules

generally trigger hot reload, but I haven't tested this specific to SST and NPM workspaces.