exile.watch engineering
  • exile.watch engineering blog
  • April 2024
    • Why doesn't Dependabot update package.json?
  • March 2024
    • The savior amidst the chaos of dependency updates - Dependabot
    • Why project's local setup instructions are not part of README?
    • Leveraging Lefthook to enforce commit guidelines at exile.watch
    • The package manager of exile.watch
    • Lerna - the hidden powerhouse of exile.watch
      • 1. Separate repository and monorepo tool
      • 2. A module bundler - the fun begins
      • 3. Module registry (a place where packages get to chill)
      • 4. Versioning, Publishing, and Configuring lerna.json for Commit Conventions
      • 5. Some automation magic using the (Lerna) CLI
      • 6. How does one test lerna packages at exile.watch: locally and in the real world
    • To open source or to not open source
    • exile.watch architecture
Powered by GitBook
On this page
  • Separate repository
  • Monorepo tool (Lerna)
  • $schema
  • version ("fixed" mode)
  • version ("independent" mode)
  • packages
  • Updating package.json to leverage NPM Workspaces

Was this helpful?

  1. March 2024
  2. Lerna - the hidden powerhouse of exile.watch

1. Separate repository and monorepo tool

2 min read

PreviousLerna - the hidden powerhouse of exile.watchNext2. A module bundler - the fun begins

Last updated 1 year ago

Was this helpful?

This page is part of list - 1/7

Following up on our deep dive into exile.watch's use of Lerna, this page tackles the first crucial steps: setting up a separate repository and introducing Lerna as our monorepo tool.


Separate repository

It was fairly straightforward—I created an empty repository through GitHub's UI

Monorepo tool (Lerna)

Running lerna init got everything prepped for a true Lerna workspace.

Although I don’t remember the exact output, I initially ended up with the following lerna.json:

// lerna.json
{
  "$schema": "node_modules/lerna/schemas/lerna-schema.json",
  "version": "independent",
  "packages": [
    "packages/*"
  ]
}

As of March 2024, let’s break down the options and definitions in the above JSON:

$schema

version ("fixed" mode)

When using the fixed mode, all the affected packages will be published using the same version. The last published version is recorded in lerna.json

.
├ package.json     # "version": 0.0.0
├ lerna.json       # "version": 1.2.3
└ packages     
  ├ package_A
  │ └ package.json # "version": 1.2.3
  └ package_B      
    └ package.json # "version": 1.2.3

version ("independent" mode)

If you decide to use independent, then every package has it's own version.

I went with independent option.

I opted for this approach because some packages will change more often than others.

.
├ package.json     # "version": deleted key, "private": true
├ lerna.json       # "version": "independent"
└ packages     
  ├ package_A
  │ └ package.json # "version": 1.2.3
  └ package_B      
    └ package.json # "version": 3.2.1

packages

Updating package.json to leverage NPM Workspaces

// package.json
{
  // ...
  {
    "workspaces": [
    "packages/*"
  ],
}

With our repository and Lerna setup ready, let's now focus on the second key piece: the module bundler, crucial for efficiently packaging our code.

Starting with an empty repository, the best approach was to follow the "" instructions from the Lerna setup guide, utilizing the npx lerna init command.

This refers to , which help to describe your JSON data structure.

Also it wasn’t necessary to version the repository's package.json, and doing so is

This is an array of indicating where packages can be found. By default, it’s set to ["packages/*"], which is how configurations for , and are structured.

The last change involved updating package.json to make the most of :

starting from scratch
CLI
JSON schemas
generally not recommended:
globs
splinters
nucleus
writ
npm workspaces
exile.watch logo
The toolkit I needed to make it all happen