[Case Study] Publish workflow
@arcanis is already working on this.
Since Aug 2, 2019.
- Dominant language
- TypeScript
- Stars
- 8.1k
- Forks
- 1.3k
- PR merge metrics
- No merged PRs in 30d
Description
Describe the goal of the investigation
It's currently a bit difficult to work on Berry due to the numerous build artifacts that we currently need to store into the repository in order for Yarn to be able to build itself (for example, since Yarn needs to be built w/ PnPify, we keep a build of PnPify in the repository for use during the build steps).
Investigation report
It's ongoing, but basically I want to:
-
Remove the checked-in build artifacts and instead add a dev dependency on the version of the package that got published last. So in a sense shortcut the workspaces for some packages only (on a quick check, it would mostly be
@berry/builderthat would have such a dependency for@berry/pnpify). -
Enforce that each PR include which packages are meant to be bumped during the next release trigger. The exact way to do that is still to be determined (advices welcome), but a good option might be semantic releases (although I don't know how they work with monorepos).
-
When doing a release, publish all the packages that have changed.
-
After the release, make one commit to update the non-workspace dependencies so that they use the newly published version.
-
Should a new release be automatically triggered with the new packages that are getting used, if any file changed?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.