Better `yarn publish`

[cpojer]

There was no time to polish yarn publish pre-release. I think we can do so much more and provide a fantastic experience (on top of the existing publish functionality).

Let's discuss what the ideal version of yarn publish may look like.

Inspiration: https://github.com/sindresorhus/np cc @sindresorhus

[umamialex]

Really love all the checks and balances np runs, but I don't like how it and yarn currently bump the version right before publish time.

Just to put out my personal preference on bumping a package, my typical workflow is as follows:

• Create a branch release/vX.x.x where the last commit is a version bump commit in package.json.
• CI does its thing and reviewers approve the release.
• A rebase merge is performed onto master.
• CI does its thing on master just in case.
• A git tag is applied onto the version bump commit.
• CI/CD does its thing on the new tag.
• npm publish is finally run on the new master.

I feel like publishing before the version bump is in source control is a little backwards. Maybe we can have a separate yarn bump? It'd also be useful for private projects that still keep track of their versioning in package.json but don't need to publish to a registry.

[grempe]

I also agree that bumping version in the working dir without committing that change is not the right flow. Yarn publish should require a clean working dir if in git so it doesn't pick up WIP.

Important side note, for me yarn publish didn't work at all. It asked me what version I wanted to bump to and then hung until ctrl-c (npm publish worked immediately after this):

$ yarn publish
yarn publish v0.16.0
[1/4] Bumping version...
info Current version: 2.0.2
question New version: 2.0.3
info New version: 2.0.3
[2/4] Logging in...
[3/4] Publishing...
^C

[MikeRalphson]

Important side note, for me yarn publish didn't work at all. It asked me what version I wanted to bump to and then hung until ctrl-c

+1 for this, Windows 10, Node 6.9.0, Yarn 0.16.0 - except I don't have npm installed... :(

[JulianLeviston]

It'd be really sweet to have some better logging for this process as it does what it does... so maybe if some step is taking longer than a second, it could log what it's been doing / what it will do, perhaps? Or at least output some form of logging or have a trace mode so we can debug where things are going a bit awry?

I just found out there's a --verbose mode :embarrassed: sorry! (but it didn't help)

[Waize]

Hi, I've investigated this a bit and found that there is a mistake in reading the stream of the tgz-file or directory, depending on what you gave as arguments.

Sticking into this shows that the chunk size of the stream (on windows, linux not tested) is 65536 byte. In the stream.js where you call the ConcatStream-Object the _transform-function ist just called once. This leads to the problem: you get the stream, read the first chunk (65536 bytes) and nothing more happens.

Hopefully this can help you to fix this issue and make publish working again.

btw: in your pack.js-file there is no problem with the stream handling and I wonder why it is in publish.js 😕

[GordonSmith]

FWIW In my case it seems related to having uncommitted changes in the folder being published.

[ghost]

The need to interactively provide a version number has been found confusing for people who have looked to adopt yarn publish as a drop-in replacement for npm publish within automated scripts.

#722 #2445 #2430

[arichiardi]

👍 throwing ideas at this 😁 yarn semver should probably do something like this clojure boot task https://github.com/degree9/boot-semver#task-options, where you can pass these https://github.com/degree9/boot-semver#helpers

[BYK]

Another idea (from @davidaurelio): Put publish behind a company SSO so all company projects are published by the same, single user account on NPM).

[cooperka]

It would be great to have a --dry-run flag for publishing.

With npm you can use npm pack to generate a tar that's exactly the same as the release contents, but using yarn pack seems to include every single file (it doesn't respect your files array or .npmignore settings). I assume these would be excluded when actually publishing, but there's no way to know without a dry-run.

[daviestar]

Currently yarn publish automatically creates a git tag, without an option to disable this. This causes problems when working with yarn workspaces, as obviously multiple packages can cause git tag collisions.

It's possible to add a tag prefix though a configuration option (ie. <package-name>2.0.1), but disabling git tagging completely on the monorepo makes most sense to me.

A workaround is something like:

yarn workspace <package-name> version --no-git-tag-version
yarn workspace <package-name> publish --non-interactive

When tasked with bumping dependencies across packages in a yarn workspace monorepo, the upgrade-interactive UI is fantastic, but when it comes to publishing the 2-liner above feels cumbersome.

[flux627]

Yesterday I accidentally did yarn publish --dry-run (instead of npm publish --dry-run) . When it asked me to give me a bumped version, I realized my mistake, thought "that was a close one," and hit Ctrl-C. Then, to my horror, yarn continued the publish. It ended up being fine, but it could have happened in a much, much worse scenario.

[darklight9811]

Would love to have a dry run option. Testing my CICD workflows without it is being a pain in the heart

[maxrdz]

Has a dry run option been implemented yet? I looked at the docs for yarn publish but it doesn't look like it has that, unless it's assumed to have all the same options that npm publish already has.