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

Yeah good point. @Frank I think we should respond to the PR here.

Taking a look at the PR now

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

Yup, will merge it today.

I don't think so

ah u mean adding

@serverless-stack/cli

as a dependency and do

npx sst env -- …

instead

yeah and for most monorepos you won't really have to add it since it'll already be in the root

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.

@Fredrik Kjellberg Huh that’s a fair point. I guess you mean in non monorepo contexts right?

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

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

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

yep agree

Both issues referenced here are released in v0.65.2 🎉