Skip to content

Maintainer's Guide

Jump to bottom
zallen edited this page Oct 21, 2021 · 7 revisions

The Monorepo

We use a monorepo because we have many inter-dependencies between our own packages (ex. react-core depends on react-styles). Taken from babel's monorepo:

Pros:

  • Single lint, build, test and release process.
  • Easy to coordinate changes across modules.
  • Single place to report issues.
  • Easier to setup a development environment.
  • Tests across modules are run together which finds bugs that touch multiple modules easier.

Cons:

  • Codebase looks more intimidating.
  • Repo is bigger in size.
  • Can't npm install modules directly from GitHub
  • ???

Dependencies

PatternFly uses yarn workspaces to manage our monorepo dependencies and inter-dependencies. Everything can be hoisted fine on Windows, OSX, and Linux. Node module resolution works great, except for sass in catalog-view-extension, which we created an importer for.

Building

We are a component library which differs from a traditional SPA in distributing our JS and CSS. Rather than using Webpack for our components to create a bundle of JS, we use Typescript to convert our source TS files to various module types, including esm, commonjs, and umd. We also publish our types .d.ts.

We use Babel plugins to support language features. PF3 uses Babel 6, and PF4 uses Babel 7.

Incremental build

Running yarn build to build all our packages takes a while on a 2015 Macbook:

real    1m43.256s
user    4m12.904s
sys     0m29.120s

Many of our packages are not updated in-between local or CI builds. We leverage tscs incremental build option to track file changes between builds and only rebuild necessary packages.

Continuous Deployment

We use GitHub Actions to continually test and generate preview links for PRs and create rolling prereleases for pushes to main.

Our pipeline looks like this:

Pipeline

Only pushes to main trigger the deploy step which uses lerna to publish packages. Lerna bumps the versions all changed packages and their dependents, pushes git tags, pushes a git commit, and then publishes to npm using GH_TOKEN and NPM_TOKEN.

Our GitHub actions config is here, along with our scripts for some of the steps. It's difficult to conditionally check whether the workflow is running in a PR or on the main branch so we need two workflow files. Most steps are duplicated between the 2, so in order to keep the pipeline DRY there's a simple templating script to generate the real workflow files.

Some things to note about the config:

  • We cache node_modules for each sub-project based off the root yarn.lock
  • We cache dist folders and selectively build the projects that have changed based off the contents of their src directories
Clone this wiki locally