![]() But it also ensures that you can have Yarn hoist all your NPM packages to the project root. This is good for keeping your Lambda packages small. It uses the serverless-bundle plugin (based on Webpack) to create optimized Lambda packages. Each service is based on our Serverless Node.js Starter. The Serverless Framework services are meant to be managed on their own. The packages/ and services/ directories are Yarn Workspaces. Any changes here should redeploy all our services. service2: Does not depend on any internal packages.Īny common code that you might not want to maintain as a package.This means that if it changes, we want to deploy service1. service1: Depends on the sample-package.These are Serverless Framework services that are deployed. Any changes to a package should only deploy the service that depends on it. Each contains a package.json and can be optionally published to NPM. These are internal packages that are used in our services. The directory structure roughly looks like: package.json But if you are not familiar with Lerna or Yarn Workspaces, make sure to check out their docs.Ĭheck out the repo here - /AnomalyInnovations/serverless-lerna-yarn-starter Installation This will help get you started with this setup. Uses Yarn Workspaces to hoist packages to the root node_modules/ directory.Supports publishing dependencies as private npm packages.Uses Lerna to figure out which services have been updated.Maintains internal dependencies as packages.SST Lerna + Yarn Workspaces Monorepo Starter.Serverless Framework Lerna + Yarn Workspaces Starter.To help get you started with this, we created two starter projects for Lerna and Yarn Workspaces together helps create a monorepo setup that allows our serverless project to scale as it grows. This helps us manage our packages, publish them, and keeps track of the dependencies between them. So that a single yarn install command installs the NPM modules for all our services and packages. This optimizes our repo by hoisting all of our separate node_modules/ to the root level. To tackle this issue we are going to use: However, managing these packages in the same repo can be really challenging. ![]() Avoiding the scenario where a small change to some common code breaks all the services that depend on it. This will allow your team to update to the newer version of the package when it works best for them. So your services could potentially be using different version of the same package. Here it makes sense to manage your common code libraries as packages. ![]() For any change made to the common code, would require all the other folks on your team to test or update their services. If your services were managed by separate folks on your team or by separate teams, this poses a problem. An update to these libraries would redeploy all your services. You have some common code libraries that are used across multiple services. This setup works pretty well but as your team and project grows, you run into a new issue. This included how to share code between your services and how to deploy a Serverless app with interdependent services. Yarn behaves differently depending on the presence of package.In the Organizing Serverless Projects chapter we covered the standard monorepo setup.Repeating my steps from above (that used yarn init -y before the install) gives the same log output as before. Info Visit for documentation about this command. Yarn-test $ echo '' > package.jsonĮrror Running this command will add the dependency to the workspace root rather than workspace itself, which might not be what you want - if you really meant it, make it explicit by running this command again with the -W flag (or -ignore-workspace-root-check). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |