Shared node modules for codecademy.com & co
This repository is a monorepo that we manage using Lerna. That means that we publish several packages to npm from the same codebase, including:
- Run
yarn
in the root directory - Run
yarn build
- Make your changes in a feature branch, and get another engineer to review your code
- At this time, determine what kind of version bump your changes will require and add the appropriate label to your PR
- If your changes are backwards compatible, you can use a
release/patch
orrelease/minor
version label - If your changes are not backwards compatible, you will need to use a
release/major
version label
- If your changes are backwards compatible, you can use a
- After your code has been reviewed and tested, you can merge your branch into main.
- Make sure to update the release notes section in your PR description, this will end up in the changelog
- You can now merge your changes
- Once your branch is merged into main, it will be published automatically by Github Actions
- You can find the new version number on npmjs.com/package/, or find it in that package's
package.json
on themain
branch
Every PR that changes files in a package publishes alpha releases that you can use to test your changes across applications.
- Create a PR or Draft PR.
- This will kickoff a Github Actions workflow which will publish an alpha build.
- After the alpha build is published, the description of your PR should update with the latest versions of the packages that were published.
- Install this version of the package in your application you wish to test your changes on.
For quicker development cycles, it's possible to run a pre-published version of a client-modules package in another project. We do that using symlinks (the following instructions assume you have set up and built client-modules):
cd /path/to/client-modules/packages/eslint-config
yarn link
cd path/to/other/repo
yarn link @codecademy/eslint-config
yarn install
- Create a new directory at
packages/<package-name>/package.json
. - Use
yarn lerna create
to create the new package, copying values from existingpackage.json
s when unsure.- Also copy the
publishConfig
field to let your published package be public by default
- Also copy the
- Create a minimal amount of source code in the new package
- Example: a simple
tsconfig.json
with aindex.ts
exporting a single object
- Example: a simple
- Run
yarn lerna bootstrap
from the repository root - Send a
feat
PR adding that package - One merged, message out in our #frontend Slack channel to other client-modules developers to re-run
yarn lerna bootstrap
after they merge frommain
Turborepo
This monorepo uses Turborepo to cache previous builds locally and in CI.
The config for Turborepo is located at /turbo.json.
To use Turborepo without extra configuration, if your package needs to be compiled, it should have a task called build
that compiles it's files and puts them into a directory called dist
inside the package directory. If you need a more complicated setup, you can read the docs and customize the configuration in turbo.json
.
Because client-modules is a separate repository from its consumers, it can be tricky to coordinate technically breaking changes. If your changes will require changes in any downstream repositories:
- Create a PR in client-modules to create alpha package versions
- Create PRs in the repositories using those alpha package versions
- Update each downstream PR description to link to the client-modules PR, and vice versa
- Once all PRs have been approved, merge your client-modules PR first
- Update your repository PRs to use the new (non-alpha) package versions once published
- Merge your repository PRs
This process minimizes the likelihood of accidental breaking changes in client-modules negatively affecting development on our other repositories.
Release Notes
This section of the PR description will be used to generate the changelog for the package(s) you changed.