Allow arbitrary publish steps

Affected Packages

pkg:cli

Problem

I would like to use changesets to trigger deployments of some packages, rather than publishing to NPM. My immediate use case is a Pulumi program, I would like to run pulumi up instead of NPM publish.

Proposed solution

Adding changesets configuration into package.json.

changesets: {
   "publish-required": "pulumi preview --expect-no-changes",
   "publish": "pulumi up"
}

getUnpublishedPackages could then check for the existence of publish-required and use it’s return code as a signal you are up to date. Otherwise "publish-state": "./scripts/get-publish-state.js", could return publishedState and published version. (must be a node script, which can be required by changesets).

Then in publishAPackage, if a publish step is defined, it is run instead of npm publish. In addition, if the old / new version are passed as command line arguments to the commands defined in these hooks a package.json file could be used to wrap anything, docker, rust packages etc without the core of changesets having to change.

It could also open up the possibility of third party packages to enable the various ecosystems. maybe something like this:

changesets: {
   "publish": "changesets-pulumi"
}

or

changesets: {
   "publish": "changesets-docker"
}

changesets: {
   "publish": "./publish.js"
}

Then that file could export getCurrentVersionInfo and publish.

[JakeGinnivan]

For what it’s worth, I have been experimenting with this further to try and contribute results to this. My approach has actually aligned with @ianwalter 's suggestion. Here is the patch for what i’m currently working with.

diff --git a/node_modules/@changesets/cli/dist/cli.cjs.dev.js b/node_modules/@changesets/cli/dist/cli.cjs.dev.js
index 9797d3b..5d015fb 100644
--- a/node_modules/@changesets/cli/dist/cli.cjs.dev.js
+++ b/node_modules/@changesets/cli/dist/cli.cjs.dev.js
@@ -638,6 +638,7 @@ async function publishPackages({
   tag
 }) {
   const packagesByName = new Map(packages.map(x => [x.packageJson.name, x]));
+  const privatePackages = packages.filter(pkg => pkg.packageJson.private);
   const publicPackages = packages.filter(pkg => !pkg.packageJson.private);
   let twoFactorState = otp === undefined ? {
     token: null,
@@ -653,7 +654,18 @@ async function publishPackages({
     logger.warn("No unpublished packages to publish");
   }
 
-  let promises = [];
+  let promises = privatePackages.filter(privatePackage => {
+      const tagName = `${privatePackage.packageJson.name}@${privatePackage.packageJson.version}`
+
+      return !tagExists(tagName)
+  }).map(privatePackage => {
+    return Promise.resolve({
+        name: privatePackage.packageJson.name,
+        newVersion: privatePackage.packageJson.version,
+        // Private packages do not need to be published
+        published: true
+      });
+  });
 
   for (let pkgInfo of unpublishedPackagesInfo) {
     let pkg = packagesByName.get(pkgInfo.name);
@@ -1202,3 +1214,8 @@ ${util.format("", err).replace(process.cwd(), "<cwd>")}
   logger.error(err);
   process.exit(1);
 });
+
+async function tagExists(tagStr) {
+    const gitCmd = await spawn("git", ["tag", "-l", tagStr]);
+    return !!gitCmd.stdout.toString().trim();
+  }

This allows the private pacakges to be published, then in my GitHub actions workflow I just add

if: steps.changesets.outputs.published == 'true'

To the deployment steps.

[emmatown]

creating tags on publish of private packages

This is something we want to do - #218. If someone wants to submit a PR for that, we’d happily accept it.

Just customizing publish steps is simpler for a lot of use cases

I don’t really see the value in Changsets itself letting you do this. It wouldn’t be very hard to use @manypkg/get-packages and implement your own publish script. It would mean that people doing this are less constrained(I can imagine some deployment scenarios where the API mentioned in https://github.com/atlassian/changesets/issues/399#issuecomment-649122163 might not work) and Changesets doesn’t need all this extra complexity and constraints on what we can do in the future with publishing.