https://serverless-stack.com/ logo
#sst
Title
# sst
f

Fredrik Kjellberg

02/14/2022, 5:20 PM
Hi! I'm trying to use SST in an existing monorepo where nested projects are not allowed. They have to be siblings. This is causing the
sst-env
script to fail when trying to find the SST project. There is a PR that fixes this issue from @Ivo Evans-Storrie waiting for review. It would be great if this PR (or some other way of solving the issue) could be included in an upcoming release. https://github.com/serverless-stack/serverless-stack/pull/1224
j

Jay

02/14/2022, 8:21 PM
Yeah good point. @Frank I think we should respond to the PR here.
f

Frank

02/14/2022, 11:39 PM
Taking a look at the PR now
t

thdxr

02/15/2022, 2:41 PM
I think we can merge this but we should re-evaluate the
sst-env
utility. I think it could be more into a more general tool and ideally not a seperate cli tool
f

Frank

02/15/2022, 2:44 PM
Yup, will merge it today.
ideally not a seperate cli tool
Would that require sst to be installed globally?
t

thdxr

02/15/2022, 2:45 PM
I don't think so
I just meant built into our existing cli, I always find it annoying to add another thing and I always forget the name of it
f

Frank

02/15/2022, 2:47 PM
ah u mean adding
@serverless-stack/cli
as a dependency and do
npx sst env -- …
instead
t

thdxr

02/15/2022, 2:50 PM
yeah and for most monorepos you won't really have to add it since it'll already be in the root
but I'd like to redo our cli anyway in one of those frameworks so maybe this can be the first step
f

Fredrik Kjellberg

02/15/2022, 3:38 PM
Can I ask you to please not include the
sst-env
script in the
@serverless-stack/cli
utility? The reason is that the `sst-env`tool is really lightweight with its 60 lines of code or something. I created a PR (https://github.com/serverless-stack/serverless-stack/pull/1347) to cleanup the current dependencies that carries over 450 packages into
node_modules
when you want to use only the
sst-env
tool. The purpose of the tool is to just inject the necessary configuration from the related SST project into e.g. a React app that is otherwise completely standalone from the SST project. I don't see the benefit of including all those dependencies from SST into a frontend app if the only functionality needed is the `sst-env`script.
j

Jay

02/15/2022, 4:13 PM
@Fredrik Kjellberg Huh that’s a fair point. I guess you mean in non monorepo contexts right?
f

Fredrik Kjellberg

02/15/2022, 4:31 PM
@Jay Yes, I think it would be great if SST would work fine in both single repos and monorepos and with all package managers. I have been testing SST in both types of repos and with
npm
and
pnpm
. Pnpm will hide all those dependencies with its strict non-flat
node_modules
structure but for smaller
npm
based single repos I think that having
sst-env
include hundreds of irrelevant dependencies is an issue.
When I tried SST with Rush based monorepos and
pnpm
, I have run into some issues with the SST dependency tree due to conflicting versions within the SST application itself. I think having the dependency tree as clean as possible would make it simpler for downstream consumers of SST.
t

thdxr

02/15/2022, 4:36 PM
part of why I want to rework our CLI is to reduce the weight of it, we're in an awkward middle state of the cli not being in TS which causes us to put any new code in core which is why there's a lot of unrelated things being shipped together. Can definitely optimize this by cleaning this up + making use of optional dependencies
f

Fredrik Kjellberg

02/15/2022, 4:51 PM
@thdxr Yeah, it may make sense to include sst-env in the cli if you refactor it to become much more lightweight than it is today. Even better if you can break up the SST project into smaller optional dependencies so you don't end up with e.g. React in your dependency tree if you are only implementing a small lambda function.
t

thdxr

02/15/2022, 4:54 PM
yep agree
f

Frank

02/17/2022, 8:20 PM
Both issues referenced here are released in v0.65.2 🎉
Thanks @Fredrik Kjellberg!