https://serverless-stack.com/ logo
Join Slack
Powered by
Hello good people! I have a question regarding sh...
# help
l
Hello good people! I have a question regarding sharing code between services in a typescript SST app. I have the following structure, where each service is its own SST app.
Copy code
libs/
   shared-component.ts
services/
   service1/
      src/
      stacks/
      package.json
      sst.json
      tsconfig.json
   services2/
      etc.
Whenever I reference 
shared-component.ts
inside any of the services I get the following error even though my service has the eslintConfig property present in package.json:
Copy code
No eslint config found. There was a change starting in SST v0.48.0 with the eslint integration for better editor support. Please add the following to your package.json:

"eslintConfig": {
  "extends": ["serverless-stack"]
}
Any suggestions to allow for typescript files shared between services? Apologies in advance if this is a totally ignorant question. This is my first adventure in typescript. Thank you!
t
We generally don't support multiple sst apps in a single repo
This is the structure I recommend along with explanations as to why I don't suggest multiple packages
l
I see. I was trying to emulate the Seed docs for setting up multiple services in a mono repo, so I could achieve more surgical deployments. Does this only apply if you’re using Serverless Framework? https://seed.run/docs/mono-repo-apps-in-seed
t
Typescript complicates things a bit
This guide might be serverless framework specific
l
Ok, got it. Thanks again for your help!
s
I have an alternative TS monorepo approach which does use multiple packages. 😅 I'll see if I can together a minimal example to demonstrate to the community for consideration.
The approach I use utilises direct TS imports form other packages, like your example @Lincoln Waddell. So no need for an annoying build step.
t
Is there a benefit of having discrete packages besides keeping deps separate?
s
I like that I don't have to keep path aliases everywhere. It's all automagic.
I also like having the dependencies in each code scope be explicit
although that isn't strictly enforced/verified
but it's handy with bin linking i suppose
if i don't depend on build output of the packages, and instead reference the ts source directly i still get all the auto rename/refactor goodness etc too
there is no need for me to build as esbuild bundles it all anyways, nothing is published as a package.
t
do you have to use relative paths to import?
s
nope
import { foo } from "@acme/lib";
that sorta thing
feels cleaner to me. but it definitely edges on the spectrum of personal preference I suppose
i think each approach has it's merits.
t
what do you have set as your 
main
in package.json in 
@acme/lib
s
nada
it's not needed
don't need the 
files
either
the resolution will work fine as it's ingesting the source
t
How does it even know where the source is?
s
yarn workspaces
t
What if it's in 
src
or 
lib
inside 
@acme/mylib
s
i don't use 
src
it's flat structure for all my packages
t
Oh I see you're pointing directly to the folder
s
yeah
no packages need building and publishing, so it's much easier
esbuild bundles and sorts for the lambda deployments
love it
l
Thanks @Sean Matheson! Would love to see an illustration. As it is, I have all of my services within the same package, but separated by stacks. Trying to achieve separate packages / applications to give me more precise deployments via Seed. Each service is more or less independent, but there are some common components I'd like to share between them
s
Sure thing @Lincoln Waddell - it's all tied into a spike I am doing for a client, but I'll lift and shift the core idea into a repository for you. 👍
Unfortunate news @Lincoln Waddell - I had to move away from this strategy as it didn't work out when I tried to customise the bundle configuration for my lambdas. This customisation seems to depend on a root package.json for the backend side. I've had to switch over to the strategy described within the example @thdxr provided. Sorry about that. I don't have the same requirements as you so it was less of a concern for me.
Open in Slack
PreviousNext
Powered by