Tag private packages when their version changes

[JakeGinnivan]

Replaces #420 and #569. Also addresses comment in #478 (comment)

This updates the publishPackage function so it returns 2 things, the publishedPackages and the untaggedPrivatePackages. I wasn't sure how far to take the separation, it could have been it's own module.

Possibly a further step would be to gather up the projects which need to be published & tagged. This would allow changesets to be extended to publish .NET packages to NuGet for instance.

This could also be considered as a breaking change. We possibly should add a new config option to opt into this?

[changeset-bot]

🦋 Changeset detected

Latest commit: 7bdce4a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@changesets/cli	Minor
@changesets/git	Minor
@changesets/config	Minor
@changesets/types	Minor
@changesets/apply-release-plan	Patch
@changesets/read	Patch
@changesets/release-utils	Patch
@changesets/assemble-release-plan	Patch
@changesets/get-release-plan	Patch
@changesets/changelog-git	Patch
@changesets/changelog-github	Patch
@changesets/get-dependents-graph	Patch
get-workspaces	Patch
@changesets/parse	Patch
@changesets/pre	Patch
@changesets/write	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[JakeGinnivan]

@gakonst @Andarist @mitchellhamilton here is another attempt, I think it addresses (or is closer to addressing) Mitchell's feedback on the other approaches.

[JakeGinnivan]

With this approach we would need to fetch tags as well, otherwise it will continually trigger releases

[vemundeldegard]

I would love this feature for tagging private packages. I have a combination of private and public. I thought this would come out of the box with Changesets, but sad to see that only published packages is getting tagged...

[Andarist]

@vemundeldegard could you describe your use case? With more data we’ll be able to take a better/more informed final decision about this

[vemundeldegard]

@vemundeldegard could you describe your use case? With more data we’ll be able to take a better/more informed final decision about this

Sure!

In our project we have a couple of private packages and a couple of public packages. The private packages are basically a handful of AWS Lambdas which are not released to NPM. We want to use Changesets because it offers a handy developer experience for managing versioning and changelog. My understanding is that Changesets do update and merge the changelogs for private our private packages, but as soon as it doesn't merge something to NPM, it will not create a new tag and a GitHub release. Please correct me if this is not right..

The above is the main drawback for us, because we use the releases to trigger additional steps in our workflow, such as deploying the Lambdas. It has forced us to only use the changeset command, and changeset version. Right now we are experimenting with using release-it to handle the tagging and releasing when a changeset PR is merged.

[JakeGinnivan]

@Andarist should I rebase this? It incorporates the feedback from @mitchellhamilton has for the previous 3 attempts

[JakeGinnivan]

I am using this via patch-package locally. As for why, I use it to control the releases of featureboard.app to production and manage my changelogs.

[miszo]

This looks neat and would address the question asked by me in #745 🙂

[JakeGinnivan]

This looks neat and would address the question asked by me in #745 🙂

@miszo Any feedback on the implementation? I think @Andarist is after someone to critically review who needs this feature. I will rebase do at least there are not conflicts to start

[miszo]

@JakeGinnivan, I guess that besides the little duplication, the implementation looks good.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 7bdce4a:

Sandbox	Source
Vanilla	Configuration

[pradel]

I would also be interested to see this one released.
For the use case, I am managing an open-source application where we have apps pushed to docker hub and packages released to npm.
I want to integrate changeset in the repository to manage the versionning + changeset of the apps published to docker as well as the packages. The docker images are built and pushed using a github action listening to git tags pushed to the main branch. The issue we have right now is that the apps are not creating a tag so the GitHub action is not triggered.

[JakeGinnivan]

Rebased on main.

[miszo]

@JakeGinnivan, @Andarist – can we proceed and merge this pull request? Are there any blockers or other reasons that suggests that this change shouldn't be merged?

[JakeGinnivan]

I've rebased again, I am referencing the packages built by codesandbox directly in a number of projects.
But when I rebase they 404 and I have to update all my projects, would love to get this merged.

[Andarist]

I think that:

• we don't have to distinguish between private and public packages externally, only publishPackages has to care about this, its return value shouldn't though
• we might want to create those tags conditionally (to not change this behavior in a minor version). We should either introduce a config flag or a CLI flag for this. Do you have any preference as to which it should be?

[JakeGinnivan]

we don't have to distinguish between private and public packages externally, only publishPackages has to care about this, its return value shouldn't though

Eventually I think this function should not actually publish, instead return the packages which should be published then have multiple publish strategies like publish to NPM, run command etc.

This will allow these private packages to maybe have a release script which can be invoked by changesets to do a custom release (to gems or something).

we might want to create those tags conditionally (to not change this behavior in a minor version). We should either introduce a config flag or a CLI flag for this. Do you have any preference as to which it should be?

Added a config flag enablePrivatePackageTracking

[JakeGinnivan]

we don't have to distinguish between private and public packages externally, only publishPackages has to care about this, its return value shouldn't though

Further to this, tagging is done outside of the publishPackages function. So I need to return the unpublished private packages so I don't need to duplicate the tagging code

[JakeGinnivan]

@Andarist have addressed feedback, rebased, added some doco and also implemented the changes in #720 which takes the config value into account so it will also fix #620

[mino01x]

is something wrong here? because config.privatePackages is always Object

!config.privatePackages?.version && packageJson.private

or i misunderstand?

[JakeGinnivan]

@mino01x is it causing an issue? If it is then we need to write a test around it

[mino01x]

#985 yes i have create a pr. you can help me to check it.

[ghost]

import type { PackageJSON } from "@changesets/types";

I think both import can be type import