And what’s the new fashion?

2022-10-31 @Gao Sun

Intro

I need to be honest: Lerna is my mentor to the concept of monorepo, and it opened a new door for me to manage big JavaScript projects. It also allows for a shared repo within the sole ecosystem (JavaScript and TypeScript, specifically) for both the frontend and backend.

Lerna is great. In the previous article, TypeScript all-in-one: Monorepo with its pains and gains, I mentioned that we were using Lerna for executing commands and publishing workspace packages. But now, it’s time to say goodbye.

The context

<aside> ℹ️ TL;DR Our project Logto used PNPM + Lerna for dependency and monorepo management.

</aside>

Why did we need Lerna?

When Lerna was born (v1.0.1, Dec 2015), the NPM official support for monorepo (or workspaces) was still far away (until Oct 2020 with NPM v7). There were several pain points for managing multiple JS packages in one repo:

None of them sounds easy, and Lerna can cover all.

The monkey-patch situation

However, Lerna does not include package manager features; thus, you still need to use NPM or something else. As you can imagine, this leads Lerna to have the “all-in-one” monorepo support to eliminate the gap across different package managers. In other words, redundancy.

I started to scaffold the project with Lerna + PNPM (not NPM) since I’m a newbie to monorepo, and using Lerna was the standard approach in my mind. But some discord popped up over time.

<aside> 💡 When it has 20% redundancy, it is acceptable; when it turns to 90%, I have a solid feeling to replace it with something more specific.

</aside>

🔗 Workspace dependencies

PNPM has a built-in command to add workspace dependencies: