https://serverless-stack.com/ logo
Join Slack
Powered by
Hey folks (and <@U01J5Q8HV5Z>)- very new to server...
# help
k
Hey folks (and @Jay)- very new to serverless-stack and have a question about project organization. I was reading https://serverless-stack.com/chapters/organizing-serverless-projects.html and it looks like there should be no issue with a monorepo and separating the cdk code from the service code, but I am having a problem building a golang lambda function when I split things up. It seems to work fine when the sst.json and lib folder are inside of the subfolder with the go code (including go.mod, go.sum), but if I move the cdk stack code into a separate folder, I get an error like:
Copy code
Preparing your SST app
Transpiling source
Synthesizing CDK
Building Lambda function ../../mygoapp/lambdas/mylambda
go: cannot find main module, but found .git/config in /Users/me/projects/myproject
	to create a module there, run:
	cd ../.. && go mod init
Currently I am trying for something like this:
Copy code
/mygoapp
/mygoapp/go.mod
/mygoapp/go.sum
/mygoapp/lambdas
/mygoapp/lambdas/mylambda
/cdk/mystack
/cdk/mystack/lib/ <- stack code
/cdk/mystack/package.json
/cdk/mystack/sst.json
If I move everything in 
/cdk/mystack
under 
/mygoapp
, everything seems to work, but I'd like to keep the cdk code separate
t
Right now I believe 
sst.json
needs to be at your project root. I think you can still keep the rest of your dir structure as is
Actually let me think about this a bit
Can I see the function code?
k
the lambda function code?
t
sorry I meant the cdk code to create the function
I think you can try setting 
srcPath
to 
../../mygoapp/
and then setting handler to 
lambdas/mylambda
srcPath is where we spawn the go builder, if it's not specified we spawn it at the same place as sst.json
k
ah
I think that may be the issue - let me try setting srcPath
that did it - thanks so much @thdxr 😄
@thdxr it seems like the automatic recompile for the lambda code is no longer working with this structure. Any idea what might be the problem?
t
Sorry didn't see this message. I'll try to recreate on my end today. We don't have a lot of people using Go so it might be under tested
ok I was able to replicate this and track down the issue. The problem is right now our filewatcher works by starting at sst.json's location and scanning for all go files inside recursively. It's why it breaks in your case. We're working on a new runtime system that'll be able to support your situation because the watcher will be specific to the srcPath per function but for now can you stick to the standard structure of having the sst project in the root? Would like to understand more around why you're looking to nest it deeper
k
I'd like a structure like:
Copy code
|- services/
|--- billing-api/
|--- notes-api/
|--- notify-job/
|- infrastructure/
|- libs/
|- package.json
as described in the link above under the monorepo section (assuming the sst.json and the cdk code would be in infrastructure for the monorepo example).
The overall goal here is to decouple the application code from the cdk / infra code.
t
Yeah you can do that for the most part, only package.json and sst.json should be in root + commands run from there
you can keep 
infrastructure/
k
k 👍
also is there an issue I can follow for the scanning issue?
Open in Slack
PreviousNext
Powered by