Deploying a monorepo via serverless CI/CD service with yarn workspaces

I have a monorepo with 2 nodejs services and a shared resource configured via yarn workspaces:

  • /services/service1
  • /services/service2
  • /packages/shared

Locally, when I run yarn, I’m able to import packages from /packages/shared in any of the services (and deploy via the cli without issue). When deploying via the serverless CI/CD service, I encounter errors because the shared resource is not available. A couple of thoughts:

  • The serverless CI flow enforces the usage of npm install to install node modules, as far as I can tell I cannot change this to yarn?
  • NPM does not support workspaces, so the /packages/shared aren’t available to the services
  • I attempted to run yarn as a post install step, which caused errors and failed (not to mention this is awful). Support referred me to https://www.serverless.com/framework/docs/dashboard/cicd/custom-scripts/ that led me to this but I haven’t figured out a working solution yet.

The serverless documentation for monorepos includes a shared directory https://www.serverless.com/framework/docs/dashboard/cicd/mono-repo/ yet I don’t see any reference for how to deploy services via the serverless CI/CD and have access to the shared code dependancy. Can anyone help me shine some light on how this should be properly setup?

tl;dr: I have a nodejs monorepo setup using yarn workspaces. I am unable to deploy services via the serverless CI/CD service that requires workspace access that yarn provides. What’s the proper way to set this up?

I found a repo that is setup similar to my own: https://github.com/AnomalyInnovations/serverless-lerna-yarn-starter

In the case above, for example, how would each service be deployed via the serverless CI/CD if they don’t have yarn workspace access to the code resource in /packages/sample-package/?

Quick update on this, it turns out that if a yarn.lock file exists with a service in a monorepo, the serverless ci/cd service will use yarn instead of npm install. It’s hacky, but placing an empty yarn.lock file in each service works.