Hooray! All contributors have signed the CLA.

🦋 Changeset detected

Latest commit: 3c9c9ab

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

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

Overall looks good but I have a few questions:

• what is the actual behavior of the npm's --dry-run? I have never used this myself. Is there any special stdout output printed for it? How close its behavior is to the real thing?
• does it work together with --json (we are using this flag)?
• it seems that it's available since npm 6, that has been released in 2018. Could we confirm though that the compatible version it's available by default on the most popular github action containers?
• is this flag supported by pnpm? if yes, could we check when it has been introduced?

And we, of course, need at least a basic test that would verify this.

@Andarist I'd like to 👍 this and potentially offer to help if I'm able. I haven't actually looked over the PR yet, so pardon any assumptions.

We currently use lerna + verdaccio in a pretty sophisticated CI workflow in order to "capture" the result of a publish and save the published tarballs as an artifact. This allows us to npm install tarballs of a package from a PR, which is really fantastic for testing changes and unblocking users who are waiting on an actual release. I'm working on a separate project which can hopefully exclusively use changesets.

So my hope for a feature like this is that the tarballs are packed and usable (in order to save as an artifact in CI). Does this seem feasible?

So my hope for a feature like this is that the tarballs are packed and usable (in order to save as an artifact in CI). Does this seem feasible?

I think this feature wouldn't quite be what --dry-run is about. This wouldn't match, AFAIK, npm's behavior for this flag (I might be mistaken though).

Where are those tarballs that you are mentioning published? What's the target for those packed artifacts? I think it would be great to open a separate issue for this.

@Andarist I think you're right...there may be some relatedness in implementation to what I'm asking for, but what I'm asking for is definitely different.

What I'm looking for is the npm pack equivalent for the whole monorepo. Happy to elaborate if that doesn't fully explain it. I think the only tricky bit here is packing the packages which are interdependent.

As for our workflow: the tarballs are currently published as an artifact in our CircleCI jobs for every PR / push. If by target you mean "how are they used", I can visit the CI job's artifacts tab, grab a url for a particular package's tarball, and npm i <url> into any project and use that package as it was built from the PR.

Here's an example of a particular build's artifacts for Apollo's federation repo:
https://app.circleci.com/pipelines/github/apollographql/federation/6561/workflows/a779c552-df37-49c8-bf06-3bc5f6b1c64a/jobs/38049/artifacts

If I copy link address for a tarball, I can just:
npm i https://38049-252760990-gh.circle-artifacts.com/0/storage/%40apollo/federation/federation-0.33.8.tgz
...and try out / share this particular build of the federation package.

I'll open a separate issue and bring along all of this context there 👍

@trevor-scheer I have some minor follow-up questions but I'm going to wait for that issue to ask them - just so we can get a clean history for this feature request and all of the context in one place.

I forgot I created this PR! I'll dust it off soon and start addressing feedback. Thank you all for your feedback.

@steve-taylor is this still in the works?

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 3c9c9ab:

@steve-taylor is this still in the works?

@silesky Yes, I finally dusted off the cobwebs and updated it. I'll test it a bit more locally then mark it as ready for review.

@Andarist

what is the actual behavior of the npm's --dry-run? I have never used this myself. Is there any special stdout output printed for it? How close its behavior is to the real thing?

NPM:

$ npm publish --dry-run
npm notice 
npm notice 📦  @my-org/[email protected]
npm notice === Tarball Contents === 
npm notice 3.8kB README.md   
npm notice 6.8kB package.json
npm notice === Tarball Details === 
npm notice name:          @my-org/my-package          
npm notice version:       6.0.5                                                 
npm notice filename:      @my-org/my-package-6.0.5.tgz
npm notice package size:  3.9 kB                                                
npm notice unpacked size: 10.6 kB                                               
npm notice shasum:        76733da1dfe70e6513b5214907aa724feff6ac90              
npm notice integrity:     sha512-L4OHeCqBDup/z[...]CAMvY513c+t9g==              
npm notice total files:   2                                                     
npm notice 
npm notice Publishing to https://npm.pkg.github.com (dry-run)

does it work together with --json (we are using this flag)?

PNPM with --json:

$ pnpm publish --dry-run --json
npm notice Publishing to https://npm.pkg.github.com (dry-run)
{
  "id": "@my-org/[email protected]",
  "name": "@my-org/my-package",
  "version": "6.0.5",
  "size": 1989510,
  "unpackedSize": 9315669,
  "shasum": "bcae4f360edc8cd484081de58b460ef12e8db6b2",
  "integrity": "sha512-ZE5WmBKjVonXpysKsDkvHOuxUId6nwCZCyCLr8F04/S6pnVImISK2HMLFWwB52wt5LSnEbCWll44l6L+cWTI/Q==",
  "filename": "@my-org/my-package-6.0.5.tgz",
  "files": [
    {
      "path": "README.md",
      "size": 3797,
      "mode": 420
    },
    {
      "path": "dist/js/index.js",
      "size": 3616884,
      "mode": 420
    },
    {
      "path": "dist/js/index.js.map",
      "size": 5688642,
      "mode": 420
    },
    {
      "path": "package.json",
      "size": 6346,
      "mode": 420
    }
  ],
  "entryCount": 4,
  "bundled": []
}

it seems that it's available since npm 6, that has been released in 2018. Could we confirm though that the compatible version it's available by default on the most popular github action containers?

ubuntu-latest seems to be the go-to environment for web dev. It has Node 14, 16, and 18 and also nvm. actions/setup-node has a node-version-file option which you can set to .nvmrc to pick up your project's .nvmrc file, so you can use a specific version of Node, installing it if necessary. So we're pretty much covered as far as npm 6+ goes.

is this flag supported by pnpm? if yes, could we check when it has been introduced?

The --dry-run option was added in v4.12.4 on April 1 2020. We're now on version 8.

And we, of course, need at least a basic test that would verify this.

@Andarist I added some tests, but I'm not sure if it's what you had in mind.

Test:

$ changeset publish --dry-run
🦋  info npm info @changesets/apply-release-plan
🦋  info npm info @changesets/assemble-release-plan
🦋  info npm info @changesets/changelog-git
🦋  info npm info @changesets/changelog-github
🦋  info npm info @changesets/cli
🦋  info npm info @changesets/config
🦋  info npm info @changesets/errors
🦋  info npm info @changesets/get-dependents-graph
🦋  info npm info @changesets/get-github-info
🦋  info npm info @changesets/get-release-plan
🦋  info npm info @changesets/get-version-range-type
🦋  info npm info get-workspaces
🦋  info npm info @changesets/git
🦋  info npm info @changesets/logger
🦋  info npm info @changesets/parse
🦋  info npm info @changesets/pre
🦋  info npm info @changesets/read
🦋  info npm info @changesets/release-utils
🦋  info npm info @changesets/types
🦋  info npm info @changesets/write
🦋  warn @changesets/apply-release-plan is not being published because version 6.1.3 is already published on npm
🦋  warn @changesets/assemble-release-plan is not being published because version 5.2.3 is already published on npm
🦋  warn @changesets/changelog-git is not being published because version 0.1.14 is already published on npm
🦋  warn @changesets/changelog-github is not being published because version 0.4.8 is already published on npm
🦋  info @changesets/cli is being published because our local version (2.27.0) has not been published on npm
🦋  warn @changesets/config is not being published because version 2.3.0 is already published on npm
🦋  warn @changesets/errors is not being published because version 0.1.4 is already published on npm
🦋  warn @changesets/get-dependents-graph is not being published because version 1.3.5 is already published on npm
🦋  warn @changesets/get-github-info is not being published because version 0.5.2 is already published on npm
🦋  warn @changesets/get-release-plan is not being published because version 3.0.16 is already published on npm
🦋  warn @changesets/get-version-range-type is not being published because version 0.3.2 is already published on npm
🦋  warn get-workspaces is not being published because version 1.0.10 is already published on npm
🦋  warn @changesets/git is not being published because version 2.0.0 is already published on npm
🦋  warn @changesets/logger is not being published because version 0.0.5 is already published on npm
🦋  warn @changesets/parse is not being published because version 0.3.16 is already published on npm
🦋  warn @changesets/pre is not being published because version 1.0.14 is already published on npm
🦋  warn @changesets/read is not being published because version 0.5.9 is already published on npm
🦋  warn @changesets/release-utils is not being published because version 0.1.12 is already published on npm
🦋  warn @changesets/types is not being published because version 5.2.1 is already published on npm
🦋  warn @changesets/write is not being published because version 0.2.3 is already published on npm
🦋  info Publishing "@changesets/cli" at "2.27.0"
🦋  error error while checking if token is required npm ERR! code E401
🦋  error npm ERR! 401 Unauthorized - GET https://registry.npmjs.org/-/npm/v1/user
🦋  error {
🦋  error   "error": {
🦋  error     "code": "E401",
🦋  error     "summary": "401 Unauthorized - GET https://registry.npmjs.org/-/npm/v1/user",
🦋  error     "detail": ""
🦋  error   }
🦋  error }
🦋  error 
🦋  error npm ERR! A complete log of this run can be found in:
🦋  error npm ERR!     /Users/steve.taylor/.npm/_logs/2023-05-01T09_41_11_907Z-debug-0.log
🦋  success packages published successfully:
🦋  @changesets/[email protected]
🦋  Creating git tag...
🦋  New tag:  @changesets/[email protected]

I think the 401 error is expected in this case. Nothing was published, of course. The only issue is that the @changesets/[email protected] tag was created, whereas the reasonable expectation is for the --dry-run option to be non-destructive and repeatable. I'll look into a change to prevent tagging.

Any way to get this over the finish line?

any plans to merge this PR?

Sorry to be the one that does the annoying "bump" messages, but would be great to land this work. 🙏

This feature of npm would be super valuable when testing CI/CD integrations that leverage the output from publishing. In that scenario, we don't want to actually publish anything but we need the resulting output to send some notification after publishing (e.g. send the names of the published packages to Slack after the publication is complete).

It looks like @steve-taylor added the avoidance of creating a git tag as well (great catch!), and now it should be possible to repeatedly call publish with no side effects in either the package or git repo with only the expected output from npm. Is there anything else needed to land this work? Is there something I can do to help?

Thanks for everyone's work on this!

Came looking for this feature. Will it ever happen?

I know many of you are watching this PR - I'd like to get more info about the need for this option. If you care about this, please join the discussion here: #614 (comment)

Any plans to get this merged?