6/16/2023 0 Comments Yarn workspacesIn my Pedalboard Monorepo there are several commands which get executed across all packages. This is the reason I will be focusing on Yarn in this post. In another post I wrote, titled “ Rethinking the “One Ring To Rule Them all” Monorepo manager”, I dealt with the issue of Monorepo’s tools and stated that I find it better for each tool to be responsible for its domain, avoiding the “all in one” approach.īecause of that reason, the tool I selected to manage my workspaces is Yarn, so Yarn is basically responsible for running commands across all packages. Lerna has the lerna run command, NX has the nx run-many and Yarn has the yarn workspaces foreach. If we take the 3 main tools out there to help us manage such a thing we will see that they all support executing commands across all packages. Luckily for us we don’t need to invent anything in order to incorporate this behavior into our Monorepo. Another example is the build command which instructs to build every package the Monorepo has. Obviously each package should have the command instructions for the test command in its package.json, but you would like to have the means to trigger the test command for all the packages under the Monorepo in one call. When you manage multiple packages on the same repo you need to have some tools to execute scripts across all the packages for good DX and for solid pipelines.įor instance, let’s take the “test” command. Perhaps together we can move from basic anecdotes of improvements to some real data showing the impact of the switch.In this week’s post join me as I stop my Monorepo from being greedy and instruct it to lint, test and build only what’s required using Yarn workspaces and some black magic spells.Ī Monorepo allows you to manage multiple packages on a single repo. If switching to Yarn improves your build times, drop a comment below and provide the timing details. You should expect an improvement in build times though since Yarn is using a shared cache for the Node artifacts and dependencies. Will you see the same kind of performance improvement? I can't promise you anything because of course it will depend upon your workspace, how many modules you have, whether you are using consistent versions. On one client we worked with that had a large number of JS-based modules using NPM, their build time on CI/CD went from ~3.5 hours to ~12 minutes. I don't have really good numbers to share, but I do have an anecdote. So you might be wondering if switching to Yarn will really do anything for you. You need to do this, otherwise Yarn will use what is already there instead of switching over to the shared Yarn cache. Sweep through your modules and remove all of the node_modules folders as well as any package-lock.json files. If you add this to an existing workspace, you have a little more work to do before you're good to go. With this setting in place, you're ready to start using Yarn (and its caching capabilities) to reduce your build times. To leverage Yarn in your Liferay Gradle Workspace, first you need to have installed Yarn, but next you just add the following to your gradle.properties file in the workspace: .manager=yarn If you want to know more about the NPM vs Yarn, I found a nice article which provides an objective comparison: I'm just going to assume that you already know about NPM and Yarn and that you're aware that Yarn still has some performance leads over NPM because of its dependency handling. And each additional JS module, while being easy to create and develop and may work great in the portal, well they just add to your build time.Īnd this can be exacerbated in a CI/CD setup since each build starts with a clean slate, so each module needs to download and resolve its own Node artifacts and dependencies.Ĭan we still have the goodness of all the JS modules yet reduce our build times? Sure we can! Yarn To The Rescue It's this repetition across what each individual JS module is doing that makes your builds take forever. Why? Well each of your JS modules are separate JS projects: they each have their own package.json files, they each manage their own set of dependencies, they each download the dependencies and they each end up with their own set of components that can sometimes be duplicated across each other. Well, as soon as you get like 3 or 4 of your JS-based portlets in your Liferay Gradle Workspace, you see that your build times just blow up. In this way, you can have your Liferay Gradle Workspace take care of building your complete suite of Liferay modules, the customizations and the portlets. In a recent blog I explained how to create a React-based portlet within your Liferay Gradle Workspace by using the js-widget Blade template which in turn uses the Yeoman Liferay JS Generator to create the project.
0 Comments
Leave a Reply. |