<@U01MV4U2EV9> : &gt; Right now sst.json needs to ...
# sst
@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 (
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
? or would it also affect
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?
@Adam Fanello
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
@Adam Fanello, are you using NPM workspaces? Does
work fine for you? It's the only thing I havent tried yet.
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
its the primary benefit of SST, after all
🤷 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
Before that I know there were a few issues people ran into when having sst.json not at the root
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!
good to know it's seemingly working
each piece of this monorepo is simple, but there are probably gonna be 7 pieces, including 2 SST and 1 CDK.
so, good test.
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)
if it references something outside it, it imports it as a package
Ah ok that was never an issue, the issue was with the following:
Copy code
And people doing
handler: "../lambdas/function.handler"
Personally I think your approach is the correct structure which is why we haven't put a lot of effort into supporting the above. I feel like boundaries aren't being properly defined when you break out of your current context but I know some people prefer it
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
generally trigger hot reload, but I haven't tested this specific to SST and NPM workspaces.
Unless the constructs are used in more than one app, I see no reason to make it a package.