When merging Pull Requests on GitHub, use the squash and merge button, so that our timeline of master branch is linear.
Also make sure every Pull Request has a PR label, and one of the semver labels (patch, minor, or major).
These labels later help generate automated changelogs.
We use Lerna for managing our monorepo. All our packages can be found in packages directory.
To start developing the packages:
Clone the repository, and run:
$ npm install
$ npm run bootstrap
Now you can run the npm scripts:
$ npm run lint
$ npm run test
$ npm run cover
Which are shortcuts for:
$ ./node_modules/.bin/lerna run lint
$ ./node_modules/.bin/lerna run test
$ ./node_modules/.bin/lerna run cover
To run npm scripts at individual package level:
$ ./node_modules/.bin/lerna run --scope frint-react test
We keep all the devDependencies at root package.json for avoiding unnecessary duplication.
To install dependencies at individual package level, just update their package.json (even if the dependency is a package from this repo itself), and run this from root:
$ npm run bootstrap
The bootstrap script takes care of installing and linking the dependencies in your packages.
To publish a new release:
$ make release
You will be prompted to select a semver (patch/minor/major), and once chosen, all your packages (that have changed) will be published to npm.
If you wish to release your packages as canary versions:
$ make release-canary
Doing so would only publish your packages to npm, without affecting your git repository in any way.
And the versions on npm would look like 1.0.0-alpha.12345678, where the last part is your commit hash.
Canary releases are useful if you want to publish nightly releases for example.
Since we use lerna for managing our monorepo, we are using lerna-changelog for generating our changelogs.
Changelog for a particular version can be generated as follows:
$ make changelog GITHUB_API_TOKEN="..." FROM_TAG="v1.0.0" TO_TAG="v2.0.0"
Doing so would output the changelog in your Terminal, which you can later add to the CHANGELOG.md file.
You can generate a token here
Since this is a public repository, you only need public_repo access for the token.
Once the CHANGELOG.md file is updated, it is up to you to commit and push it to GitHub.
There is a handy command available:
$ make push-changelog
We also copy the generated changelog text of a specific version to GitHub Releases section.
Show all the packages with their versions in the repository:
$ make list-packages
Show packages that have been updated locally, and needs publishing:
$ make list-updated