Serverless + Typescript (with references) + Yarn workspaces + Lerna example mono repo

Hey all.

The past 2 days I’ve been compiling best practices from the mentioned stack here:

Would love to see people use this and make it better together.

It’s pretty tough to get this to work, because serverless doesn’t work well with mono repos. But by disabling hoisting it (mostly) works.



1 Like

Hi Tom!

This is a really funny coincidence because I ran into your repository about 2-3 hours ago and had starred it for reference.

The monorepo + serverless usage is quite poor now and we have been getting by, using hacks here an there. We decided to attempt to do it right once again. Using your repository as an example, we implemented the no-hoist solution. The issue was that we kept running into RangeError: Maximum call stack size exceeded during Excluding development dependencies. Was this something you ever experienced? If so, how did you resolve it?


Great, let’s raise the awareness of the poor mono repo support in the community so we can fix this!

Re your error: sounds like this might happen when you have a lot of dependencies and this causes a serverless issue. See their logic here:

This is worth creating an issue for at the serverless github.

Note that I am considering to filter production only dependencies using a hack described here:

Reason is that the beforementioned logic is bugged and leaves a few redundant dev dependencies. I should really create an issue for this at the serverless framework but haven’t found the time to make a reproducable test case. If you do find this time that would be great.

This might also resolve your issue.

I’ve created an example here:

What do you think? My biggest problem with it is that it takes about 60 seconds to run for me.

@tommedema thanks for your reply. we will do our part to raise awareness on serverless + monorepo.

as a developer, if you are using serverless, you also are probably maintaining more code in your codebase. therefore it follows that a serverless user is very likely to benefit from a monorepo solution.

btw, the way we resolved our issue was by removing a bloated package from the dependencies.

we also took a deep look into how serverless packages and zips files. the pattern matching algorithm in our usecase was mapping to about 200,000 files. processing all of those guys takes a reaaaaallly long time. so i actually like your approach to highjack the artifact generation, as the current algorithm is a bit inefficient. it definitely gets the job done for small code bases, but cant keep up on the bigger ones.

we had to rewrite a big package we’ve been using all over our codebase, in order to shrink the size, and the number of files the algorithm needs to process.

thanks for your help, and your initiative in creating this example codebase. it has helped us quite a bit, and i’m sure lots of other people will find it helpful too!

1 Like