https://serverless-stack.com/ logo
Join Slack
Powered by
Question about mono-repo structure: I have a bunch...
# sst
a
Question about mono-repo structure: I have a bunch of SLS services that I’m planning to migrate to SST. Now, each of my services have their own 
package.json
file today, due most of them have totally different dependencies between each other. How is supposed that I can do the same with SST? For example, I have a bunch of lambdas under the 
user
service that uses the 
jsonwebtoken
dependency. Of course I don’t want to share that dependency with every other service. Based on mono-repo examples, all shared a 
package.json
on the root, at the same level as the 
sst.json
file, then all the projects are built with the same dependencies, I guess. Anybody else has any thoughts?
t
I think the SST GitHub has a mono repo example with different package.json per service
f
@Adrián Mouly So you can have multiple services within the same SST app, and each service has their own package.json. For example:
Copy code
/
  sst.json
  libs/ <- CDK code
  services/
    users/
      package.json
      listUsers.js
      getUser.js
    posts/
      package.json
      listPosts.js
      getPost.js
For 
listUsers
and 
getUser
, make sure you set the 
srcPath
to 
users
And for 
listPosts
and 
getPost
, set the 
srcPath
to 
posts
s
Hey Adrián, I'm doing the exact same thing and have my repo already set up. I'm happy to share some tips once I get to a computer (I'm on mobile right now)
@Adrián Mouly so.. it’s all about yarn workspaces. I think the commands might differ because I’m using Yarn 2, but the concept is the same. the repo Frank linked to was my starting point. basically you do 
yarn init
at the root, and inside every “sub-repo” folder (let’s say you have 
services/service1
and 
services/service2
). then at the root level, you edit package.json and add 
"workspaces": ["services/*"]
yarn workspaces list
run at the root level will show the list of all the projects in 
services
. to add a package to service1, just do 
yarn workspace service1 add some-package
(e.g. 
yarn workspace <workspace name> <command>
) the package you add will be written to service1's package.json, but it will physically exist in 
node_modules
at the root level (it’s hoisted up to the monorepo root). and inside 
service1
, you’d just import the package as if it existed in that current folder. yarn will figure out where to find it
bonus: I highly recommend Yarn 2. it’s blazing fast, and has lots of awesome features. this is my usual set up:
Copy code
$ yarn init -y
$ yarn set version berry
$ yarn config set nodeLinker node-modules # definitely do this, otherwise yarn will default to PnP mode which doesn't work with SST
$ yarn plugin import typescript # auto adds @types/* for packages you add
$ yarn plugin import interactive-tools # provides "yarn upgrade-interactive" command
and finally (if you do use Yarn 2), be sure to add the proper entries to your .gitignore (the second list, since you’re not using zero-installs): https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
a
Thank you gusy! Yes, I did something similar with yarn workspaces @Sam Hulick . Actually this is the repo I’ve followed, was shared by somebody here: https://github.com/lukewyman/karaoke-backend-sst I liked the folder structure due it uses TS, the oficial one it’s more focused on JS-way.
Going to read all your messages in more detail now. Thanks for taking the time.
t
wow did not realize I wasn't using yarn 2 this whole time
a
Haha, yarn + lerna, those are doing all the magic.
Are so cool that you don’t even notice are there.
s
@thdxr ha, same here for a long time. But typically you install yarn 1 globally, then install yarn 2 on the project level
a
@Sam Hulick thanks for sharing this, I had wanted to switch to yarn 2 long back but couldn’t do so because of no proper migration guide. Any comments on the topic of npm 7 vs yarn 2, what might I miss or gain by using one or another?
s
@Ashishkumar Pandey I haven’t personally used npm 7, but I haven’t heard good things about it. you shouldn’t miss out on anything. the consensus is that yarn 2 is superior. and yarn 2's PnP/zero-install is pretty neat.. basically no node_modules (packages live in 
.yarn/cache
instead), and you commit all of the package info to your repository. so while the repo can be large, the benefit is that your CI/CD doesn’t need to run 
yarn install --immutable
since the packages are already there and at the proper version. but lots of frameworks like SST & Serverless Framework don’t support this yet. there’s an esbuild plugin that enables PnP (https://github.com/yarnpkg/berry/tree/master/packages/esbuild-plugin-pnp) which does indeed work, but doesn’t seem to work within an SST project for some reason
a
okay. Sounds good. @thdxr could we add yarn 2 pnp support on the roadmap, it would be a great upgrade I believe.
t
Been on my list to understand better
Will make an issue
a
oh, cool. Thank you. 🙏
s
@thdxr if you follow the esbuild plugin instructions above, you’ll get an error. I forget what it was though. but in a fresh, plain ol’ TS project, the yarn 2 PnP + esbuild plugin setup works great
t
Will look into it tomorrow
s
great! subscribed. lemme know if you need any help
t
lol it looks like 
berry
now points to yarn 3
Moving too fast!
s
ooh wow. then 
yarn set version 2
might be a better idea. not sure how stable 3.x is
ah I see. berry is just the latest release on dev trunk. 3.x introduces breaking changes, hence the major version bump.
t
do you want me to get things working with yarn 2 or should I test with yarn 3?
a
yarn 3 looks too new, I think yarn 2 should be our initial step and we’ll then incrementally adopt yarn 3 later.
s
yeah, yarn 2 should be good. though again, yarn 3 only got that version bump due to some breaking changes. so if SST eventually works with PnP in yarn 2, it should work with yarn 3 as well
t
The first issue I'm running into is 
tsc
does not seem compatible with yarn pnp
It's not able to find the dependencies when compiling, but digging further
a
yep, I would still want to wait a few patch versions to wait for any critical fixes.
there’s a typescript plugin imported using 
yarn plugin import typescript
, would that help?
t
I think tsc has to be run via 
yarn pnpify tsc
s
@thdxr so.. the yarn PnP esbuild plugin handles all that automatically. but if you run tsc or node on a file in a PnP project, the first thing that has to happen is 
require('./.pnp.cjs').setup()
which makes it possible to `require`/`import` dependencies that would normally be found in node_modules
not sure if that helps at all
t
We call 
tsc
directly when running 
sst start
to make sure type checking passes
s
gotcha
t
I'm realizing there's going to be some cascading issues, this might be something that's a better fit once we nail down an extensibility framework
Otherwise it's going to be a bit tricky to make things work well for people who aren't using pnp and for those who are
s
I wouldn’t sweat PnP support too much. most frameworks don’t have it 😄
definitely feels like something that belongs under the “nice to have” category
a
This isn’t a priority. Give me ECS and Fargate and AppMesh please, I’ll be forever indebted. 😅
a
AppMesh +1
t
If you haven't wrote it up somewhere I'd love to hear about how you're using AppMesh and what you can imagine SST doing for you. When you have some time could you post that as a message in #sst
a
oh sure, I will. Thank you. 🙏
6 Views
Open in Slack
PreviousNext
Powered by