Skip to content

[Case Study] Publish workflow #326

Open
@arcanis

Description

@arcanis

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/builder that 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?

Metadata

Metadata

Assignees

Labels

case studyPackage compatibility report

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions