Why Monorepo

Make it easy to modify between associated repositories

When a Feature development or bug fix spans multiple Git repositories, you might wonder why not put them in one repository.

Put it in a warehouse

So you put multiple packages in the same warehouse, and then you find:

The new problem

  1. Dependency reinstallation problem

  2. Packet reference problem, how to link

  3. Post questions

    1. How do YOU know which packages have been changed?

    2. Do all these changes need to be issued?

    3. What about Changelog when sending packets

    4. Who will update the new version number of the package that needs to be issued and how to deal with the version number?

      Major? Minor? Patch?

    5. Does the following command need to be mechanically repeated in the packet dispatch?

      1. cd xxx

      2. npm publish

How to solve

1. workspace

Workspace can solve the above problems 1 and 2.

Using PNPM workspace as an example, add the workspace configuration file pnpm-workshop.ymal

packages:
  - "packages/**"
Copy the code

At this point PNPM will help you extract the public dependencies and install them into the root directory, and will automatically give link the package that matches the version. For example, if you import packageB from packageA, you will import the code directly from the packageB directory instead of downloading it from the NPM repository.

2. Version management tool: Lerna/ Changesets

If a Git repo contains only one project, all changes (changelog) from the package since the last release can be obtained from the git commit information, and further semantic versions can be generated and published based on this information with a semantic-release.

In multi-package scenarios (where a repo contains many packages), many packages need to be published at a time, and each package needs its own version and Changelog. Changelog cannot use the COMMIT information directly, because the RepO only has one COMMIT representing all package changes. A tool is needed to record changes to each package individually.

Lerna and Changesets are tools created to address these publishing issues.

Lerna’s main capabilities:

  1. Build a new version.
  2. Lerna-changelog generates only one Set of Changelog. All packages are the same
  3. Publish all packages in one click

Changesets main capabilities:

  1. Each package generates a new version separately.
  2. Changelog is generated respectively
  3. A key to release

The key aspect of Changesets compared to Lerna is its more flexible and fine-grained control over each package.

conclusion

Therefore, the common solutions of Monorepo are Lerna/ Changesets + YARN/PNPM workspace, which solve different problems respectively.

Changesets Outlines the workflow

  1. Add the Changeset tool. Initialize to generate a. Changesets folder

  2. Adding Changesets. Each Changeset logs the following information:

    1. Which packages are modified
    2. Version type for each package (following Semver)
    3. Change Information (Changelog) for each package

    This information will be generated and stored in the.Changesets directory. You can accumulate multiple Changesets and publish them at the same time

  3. Versioning and publishing, generate and publish the version. At this point, all changesets are consumed and versions and Changelog are generated based on the information