0.0.4 • Published 7 months ago

@jsenv/monorepo v0.0.4

Weekly downloads
-
License
MIT
Repository
github
Last release
7 months ago

@jsenv/monorepo

Helpers to manage multiple packages from a single repository. For example when using NPM workspaces.

This packages helps to perform 2 tasks that are a bit painful to do "by hand" inside a monorepo: "publish a new version" and "upgrade dependencies".

Publish a new version

Publishing a new version of a package in a monorepo by hand is time consuming and error prone. It's because you have to ensure packages versions are properly updated according to their inter-dependency. Let's see it with a basic example where a monorepo contains two packages and you make a change to one of them.

packages/main/package.json:

{
  "name": "main",
  "version": "3.4.2",
  "dependencies": {
    "util": "1.0.0"
  }
}

packages/util/package.json:

{
  "name": "util",
  "version": "1.0.0"
}

Now you update "version" in "packages/util/package.json"

{
  "name": "util",
- "version": "1.0.0"
+ "version": "1.1.0"
}

At this point you are supposed to update "packages/main/package.json" like this:

{
  "name": "main",
- "version": "3.4.2",
+ "version": "3.4.3",
  "dependencies": {
-   "util": "1.0.0"
+   "util": "1.1.0"
  }
}

In a monorepo with many packages this is hard to do correctly and time consuming. You can automate the painful part as follows:

  1. Run syncPackagesVersions
  2. Review changes with a tool like "git diff"
  3. Run publishPackages

syncPackagesVersions

syncPackagesVersions is an async function ensuring versions in all package.json are in sync for all packages in the workspace. It update versions in "dependencies", "devDependencies" and increase "version" if needed. This ensure all versions are in sync before publishing.

import { syncPackagesVersions } from "@jsenv/monorepo";

await syncPackagesVersions({
  directoryUrl: new URL("./", import.meta.url),
});

Review changes

Each package might need to increase their package.json "version" differently. When it's required syncPackagesVersions increases PATCH number ("1.0.3" becomes "1.0.4"). After that it's up to you to review these changes to decide if you keep PATCH increment or want to increment MINOR or MAJOR instead.

publishPackages

publishPackages is an async function that will publish all packages in the monorepo on NPM. But only the packages that are not already published.

import { publishPackages } from "@jsenv/monorepo";

process.env.NPM_TOKEN = "token_auhtorized_to_publish_on_npm";

await publishPackages({
  directoryUrl: new URL("./", import.meta.url),
});

Upgrade dependencies

As a maintainer of a package with many dependencies you periodically want to check if there is new versions of your dependencies to stay up to date. We'll first see what NPM packages are usually doing and why it's a problem. Then we'll see how to avoid that problem. Finally we'll see how to use a function to upgrade dependencies because it can be a bit time consuming to do by hand.

NPM introduced what usage of ^ or "*" in your package.json.

{
  "dependencies": {
    "foo": "^1.0.0"
  }
}

But it causes a problem.

The problem

As a result "npm install" auto updates to latest versions if any is found. In the end any npm install can change the behaviour of your code if a new version was published since the last npm install.

The sequence of events looks as below

[7h00] npm install
[7h01] npm downloads `foo@1.1.0`
[7h30] `foo@1.2.0` is published on NPM
[8h00] npm install
[8h01] npm downloads `foo@1.2.0`

Whenever you or someone else ends up with foo version 1.2.0 it can break the code or lead to different code behaviour. People will loose time trying to understand what's going on only to realize it comes from the new version.

But package-lock.json fixes that right?

package-lock.json fixes that but only if you run npm ci. And people are still used to start a project using npm install + npm start.

The problem is that npm install does too many things. Most of the time you don't want to update your deps. The 2 most common scenarios are:

  • "I want want to install deps on a fresh project"
  • "I want to ensure my deps are in sync after git pull in a branch"

"I want to update all my deps" happens from time to time but is usually not what you had in mind before executing "npm install"

Moreover the usage of package-lock.json remains optional.

How to avoid the problem

Use explicit version in the package.json

BAD

{
  "dependencies": {
    "foo": "^1.0.0",
    "bar": "2.*"
  }
}

GOOD

{
  "dependencies": {
    "foo": "1.1.3",
    "bar": "2.0.0"
  }
}

As a result there is no ambiguity on the version being used and we know the exact version in the glimpse of an eye. You control when the version gets updated

Once versions are fixed you can update whenever you want by running "npm outdated" and decide what to update by hand.

But inside large codebases with a lot of packages this process takes time, you can use the following function to perform "npm outdated" + update the versions in the package.json

import { upgradeExternalVersions } from "@jsenv/monorepo";

await upgradeExternalVersions({
  directoryUrl: new URL("./", import.meta.url),
});
0.0.4

7 months ago

0.0.3

7 months ago

0.0.2

7 months ago

0.0.1

7 months ago