7/4/2023 0 Comments Yarn workspaces![]() create 2 independent apps a NextJS and another React SPA.We'll be creating a common library, will be shared to a NextJS site and also to a single page React application. There are other vendors in the business such as Lerna, Nx, or even the latest version of npm. Yarn is not the only tool to achieve this, but it is great because of its simplicity. Given this introduction, imagine having independent NextJS and React apps or native depending and linking the same hook, both apps living in the same repository but isolated. It gets painful to have to repeat the code, that's where monorepo architecture comes to help, to have reusable code in the same repo, and also avoiding to reference company packages from a different repo (which gets messy). Let's be honest, everyone starts learning NextJS using the monolith approach, which is ok, but what happens when your codebase starts growing and duplicating patterns, hooks, or the same components over and over again. This blog post will be part of another series. With NX all dependencies stay in the root of the project, but that is ok as we have an internal dependency graph that allows us to generate a package.json with all the dependencies needed by one monorepo project.This approach has served Google well for more than 16 years, and today the vast majority of Google's software assets continue to be stored in a single, shared repository. It has a very good documentation and provides countless tools to speed up our work. For monorepos with loads of JS projects, I would use NX without a doubt. I have used NX and Bazel, which have proved very useful in different scenarios. ![]() If you’ve decided to go the monorepo route, I would strongly suggest that you invest some time and adopt a build system. I use Lerna to run scripts in a group of projects and have better visibility over the console output. It is now maintained by Nrwl, which also has the NX build system. It also provides some very useful tools on top of that which help us run projects, track dependencies, give us better logs, etc. Lerna even uses yarn workspaces behind the scenes when possible. I have to start by saying lerna is not a replacement for yarn workspaces. On my machine, I run yarn install and don’t care about the file size, because I want to be able to run all projects, but if I have a docker build only for service-a, when i use the global package.json would install some unnecessary libs, which would cost me build time and container disk space. The biggest hurdle arrives when you want to package those projects for production. Yes, this would work and even if the services a and b at some point decide to use jQuery with a higher version it wouldn’t be an issue. |_webapp-a (uses jQuery) // jokes on me nobody uses that in 2023 Consider having the following folder structure: node_modules Let me explain why it was a bad idea for me. It is more or less the same story here, with the only difference being that you have more freedom to put global npm modules for each project, but it is not recommended and neither would I recommend doing this. Old versions of yarn workspaces and lerna would always use the highest found version for some reason. I thought it would make sense that webapp-a here would use its v1 lodash node module, but I was completely wrong. For example, imagine we have the following folder structure. Why was that necessary? Because of the way yarn is used to search for libraries. This is still recommended to this day, but we can work around it. What I had to do then is be very careful about versioning and make sure that all projects use the same versions of a library. When I first started using workspaces they were not very refined and lerna was about to be deprecated. With that in mind, I will share what I have done. (if you use react 18.1.5 in one package it should be the same for all other workspaces)įirst of all, things have changed, tools have evolved and many newly emerged tools help us with the task. Also, do your best to have the same version for node modules in all of your workspace packages. ![]() If you want the TLDR: all modules, which affect the workspace should be in the root of the workspace and all project dependencies should be in each project's folder (so yeah potentially we would have one library in all project folders). ![]() However, I've not stopped searching for the answer and can share my opinion. It has been a long time and this still hasn't been answered. ![]()
0 Comments
Leave a Reply. |