Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All the new Monorepo things #1727

Merged
merged 22 commits into from
Oct 9, 2019
Merged
Changes from 21 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 5 additions & 34 deletions .changeset/README.md
Original file line number Diff line number Diff line change
@@ -1,37 +1,8 @@

# Changesets

Hello and welcome! This folder has been automatically generated by `@atlaskit/build-releases`, a build tool that works with `bolt` to help you release components from a mono-repository. You can find the full documentation for it [here](https://www.npmjs.com/package/@atlaskit/build-releases)

To help you get started though, here are some things you should know about this folder:

## Changesets are automatically generated

Changesets are generated by the `build-releases changeset` command, though it may have been given a new name within your repository. As long as you are following a changeset release flow, you shouldn't have any problems.

## Each changeset is its own folder

We use hashes by default for these folder names to avoid collisions when generating them, but there's no harm that will come from renaming them.

## Changesets are automatically removed

When `build-releases version` or equivalent command is run, all the changeset folders are removed. This is so we only ever use a changeset once. This makes this a very bad place to store any other information.

## Changesets come in two parts

You should treat these parts quite differently:

- `changes.md` is a file you should feel free to edit as much as you want. It will be prepended to your changelog when you next run your version command.
- `changes.json` is a file that includes information about releases, what should be versioned by the version command. We strongly recommend against editing this directly, as you may make a new changeset that puts your bolt repository into an invalid state.

## I want to edit the information in a `changes.json` - how do I do it safely?

The best option is to make a new changeset using the changeset command, copy over the `changes.md`, then delete the old changeset.

## Can I rename the folder for my changeset?

Absolutely! We need unique hashes to make changesets play nicely with git, but changing your folder from our hash to your own name isn't going to cause any problems.

## Can I manually delete changesets?
Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
with multi-package repos, or single-package repos to help you version and publish your code. You can
find the full documentation for it [in our repository](https://github.com/changesets/changesets)

You can, but you should be aware this will remove the intent to release communicated by the changeset, and should be done with caution.
We have a quick list of common questions to get you started engaging with this project in
[our documentation](https://github.com/changesets/changesets/blob/master/docs/common-questions.md)
82 changes: 0 additions & 82 deletions .changeset/config.js

This file was deleted.

7 changes: 7 additions & 0 deletions .changeset/config.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
{
"$schema": "https://unpkg.com/@changesets/[email protected]/schema.json",
"changelog": "./getChangelogEntry",
"commit": false,
"linked": [],
"access": "public"
}
37 changes: 37 additions & 0 deletions .changeset/getChangelogEntry.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
const { getInfo } = require('@changesets/get-github-info');

const getReleaseLine = async (changeset, type) => {
const [firstLine, ...futureLines] = changeset.summary
.split('\n')
.map(l => l.trimRight());
const { links } = await getInfo({
repo: 'keystonejs/keystone-5',
commit: changeset.commit,
});
return `- ${links.commit}${links.pull === null ? '' : ` ${links.pull}`}${
links.user === null ? '' : ` Thanks ${links.user}!`
} - ${firstLine}\n${futureLines.map(l => ` ${l}`).join('\n')}`;
};

const getDependencyReleaseLine = async (changesets, dependenciesUpdated) => {
if (dependenciesUpdated.length === 0) return '';
const { links } = await getInfo({
repo: 'keystonejs/keystone-5',
commit: changeset.commit,
});

const changesetLinks = changesets.map(
changeset => `- Updated dependencies [${links.commit}]:`
);

const updatedDepenenciesList = dependenciesUpdated.map(
dependency => ` - ${dependency.name}@${dependency.version}`
);

return [...changesetLinks, ...updatedDepenenciesList].join('\n');
};

module.exports = {
getReleaseLine,
getDependencyReleaseLine,
};
10 changes: 4 additions & 6 deletions .circleci/config.yml
Original file line number Diff line number Diff line change
@@ -32,14 +32,13 @@ x-integration-steps: &integration-steps
steps:
- checkout
- restore_cache: *restore-cache
- run: sudo yarn global add bolt
- run:
name: Bolt - Install packages
command: CYPRESS_CACHE_FOLDER=$CIRCLE_WORKING_DIRECTORY/node_modules/cypress/.cache/ bolt
name: Yarn - Install packages
command: CYPRESS_CACHE_FOLDER=$CIRCLE_WORKING_DIRECTORY/node_modules/cypress/.cache/ yarn
- save_cache: *save-cache
- run:
name: E2E Cypress tests
command: CYPRESS_CACHE_FOLDER=$CIRCLE_WORKING_DIRECTORY/node_modules/cypress/.cache/ bolt ws run cypress:run:ci --only-fs $PROJECT_DIRECTORY
command: CYPRESS_CACHE_FOLDER=$CIRCLE_WORKING_DIRECTORY/node_modules/cypress/.cache/ yarn --cwd $PROJECT_DIRECTORY cypress:run:ci
- run:
name: Prepare artifacts
command: |
@@ -71,11 +70,10 @@ jobs:
- run: psql -d $TEST_DATABASE_URL -c "CREATE SCHEMA keystone;"
- run: psql -d $TEST_DATABASE_URL -c "CREATE USER keystone5 PASSWORD 'k3yst0n3';"
- run: psql -d $TEST_DATABASE_URL -c "GRANT ALL ON SCHEMA keystone TO keystone5;"
- run: sudo yarn global add bolt
# Set Cypress cache dir here, in case this job runs/completes first, and
# hence clobbers the `node_modules` cache with a non-cypress version,
# causing the other job to fail with a "Missing Cypress" error.
- run: CYPRESS_CACHE_FOLDER=$CIRCLE_WORKING_DIRECTORY/node_modules/cypress/.cache/ bolt
- run: CYPRESS_CACHE_FOLDER=$CIRCLE_WORKING_DIRECTORY/node_modules/cypress/.cache/ yarn
- save_cache: *save-cache
# run tests!
- run: yarn lint:eslint --format junit -o reports/junit/js-lint-results.xml
7 changes: 2 additions & 5 deletions .github/workflows/release.yml
Original file line number Diff line number Diff line change
@@ -16,14 +16,11 @@ jobs:
- name: Setup Node.js 10.x
uses: actions/setup-node@master
with:
version: 10.x

- name: Install Bolt
run: npm install --global bolt
node-version: 10.x

- name: Install Dependencies
# we have a postinstall script that uses is-ci which doesn't yet detect GitHub Actions
run: CI=true bolt
run: CI=true yarn

- name: Create Release Pull Request
uses: changesets/action@master
88 changes: 40 additions & 48 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -24,72 +24,66 @@ If you develop custom fields, adapters, apps or any other Keystone feature, (or

KeystoneJS adheres to the [Contributor Covenant Code of Conduct](code-of-conduct.md).

## Version management
## Repository Setup

Keystone uses @noviny's [@changesets/cli](https://github.com/noviny/changesets) in combination with `bolt` to track package versions and publish packages.
KeystoneJS follows the [Thinkmill Monorepo Style Guide](https://github.com/Thinkmill/monorepo). For more information on the reasoning behind using certain tooling, please refer to it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏


### Version management

Keystone uses @noviny's [@changesets/cli](https://github.com/noviny/changesets) to track package versions and publish packages.
This tool allows each PR to indicate which packages need a version bump along with a changelog snippet.
This information is then collated when performing a release to update package versions and `CHANGELOG.md` files.

### What all contributors need to do
#### What all contributors need to do

- Make your changes (as per usual)
- Before you make a Pull Request, run the `bolt changeset` command and answer the questions that are asked. It will want to know:
- Before you make a Pull Request, run the `yarn changeset` command and answer the questions that are asked. It will want to know:
- which packages you want to publish
- what version you are releasing them at
- a message to summarise the changes (this message will be written to the changelog of bumped packages)
- Before you accept the changeset, it will inform you of any other dependent packages within the repo that will also be bumped by this changeset. If this looks fine, agree, and a changeset will be generated in the `.changeset` directory.
- Before you accept the changeset, it will display all the data that will be written to the changeset. If this looks fine, agree, and a changeset will be generated in the `.changeset` directory.

Each changeset contains two files; `changes.json`, which contains structured data which indicates the packages which need to be updated, and `changes.md`, which contains a markdown snippet which will be included in the `CHANGELOG.md` files for the updated packages.

Here is what a `changeset.json` looks like:
After this, a new changeset will be added which is a markdown file with YAML front matter.

```
{
"releases": [
{ "name": "@keystone-alpha/adapter-mongoose", "type": "patch" },
{ "name": "@keystone-alpha/keystone", "type": "minor" }
],
"dependents": []
}
-| .changeset/
-|-| UNIQUE_ID.md
```

An example, if you generate a changeset that includes `adapter-mongoose` as a patch, and `keystone` as a minor, you can merge your PR, and the next time the `version-packages` command is run, these will both be updated.
The message you typed can be found in the markdown file. If you want to expand on it, you can write as much markdown as you want, which will all be added to the changelog on publish. If you want to add more packages or change the bump types of any packages, that's also fine.

You can have multiple changesets in a single PR. This will give you more granular changelogs, and is encouraged.
While not every changeset is going to need a huge amount of detail, a good idea of what should be in a changeset is:

## Release Guidelines
- WHAT the change is
- WHY the change was made
- HOW a consumer should update their code

## Publishing
An example, if you generate a changeset that includes `adapter-mongoose` as a patch, and `keystone` as a minor, you can merge your PR, and the next time the `version-packages` command is run, these will both be updated.

### How to do a release
```md
---
'@keystone-alpha/adapter-mongoose': patch
'@keystone-alpha/keystone': minor
---

> This should only ever be done by a very short list of core contributors
A very useful description of the changes should be here.
```

Releasing is a two-step process. The first step updates the packages, and the second step publishes updated packages to npm.
You can have multiple changesets in a single PR. This will give you more granular changelogs, and is encouraged.

#### Steps to version packages
### Release Guidelines

The first step is `bolt version-packages`. This will find all changesets that have been created since the last release, and update the version in package.json as specified in those changesets, flattening out multiple bumps to a single package into a single version update.
### Publishing

The `bolt version-packages` command will generate a release commit, which will bump all versions, necessary dependency version changes, and update changelog.mds.
#### How to do a release

The commands to run are:
> This should only ever be done by a very short list of core contributors

```sh
git checkout master && \
git pull && \
git branch -D temp-release-branch && \
git checkout -b temp-release-branch && \
bolt fresh && \
bolt build && \
bolt version-packages && \
bolt format && \
git add . && \
git commit -m "Prepare release" && \
git push --set-upstream origin temp-release-branch
```
Releasing is a two-step process. The first step updates the packages by merging the versioning PR, and the second step publishes updated packages to npm.

Once you have run this you will need to make a pull request to merge this back into master.
#### Versioning packages

The [Changesets release GitHub action](https://github.com/changesets/action) will open a PR that versions all of the packages

#### Release Process

@@ -98,26 +92,25 @@ Once the version changes are merged back in to master, to do a manual release:
```sh
git checkout master && \
git pull && \
bolt && \
bolt publish-changed && \
yarn && \
yarn publish-changed && \
git push --tags && \
bolt
yarn
```

The `bolt publish-changed` command finds packages where the version listed in the `package.json` is ahead of the version published on npm, and attempts to publish just those packages.
The `yarn publish-changed` command finds packages where the version listed in the `package.json` is ahead of the version published on npm, and attempts to publish just those packages.

Because of this, we should keep the following in mind:

- Once the `publish-changed` command has been run, the PR from the `temp-release-branch` should be merged before any other PRs are merged into master, to ensure that no changesets are skipped from being included in a release.
- There is no reason you should ever manually edit the version in the `package.json`

### A quick note on changelogs
#### A quick note on changelogs

The release process will automatically generate and update a `CHANGELOG.md` file, however this does not need to be the only way this file is modified. The changelogs are deliberately static assets so past changelogs can be updated or expanded upon.

In addition, content added above the last released version will automatically be appended to the next release. If your changes do not fit comfortably within the summary of a changelog, we encourage you to add a more detailed account directly into the `CHANGELOG.md`.

## Build Process
### Build Process

Some of the packages in keystone-5 need to compiled before they're published, we use [preconstruct](https://github.com/preconstruct/preconstruct) to do this.

@@ -136,7 +129,6 @@ Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/d
<!-- ALL-CONTRIBUTORS-LIST:START - Do not remove or modify this section -->

<!-- prettier-ignore -->

<table>
<tr>
<td align="center"><a href="http://www.thinkmill.com.au"><img src="https://avatars3.githubusercontent.com/u/872310?v=4" width="100px;" alt="Jed Watson"/><br /><sub><b>Jed Watson</b></sub></a><br /><a href="https://github.com/keystonejs/keystone-5/commits?author=JedWatson" title="Code">💻</a></td>
Loading