npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

publish-current-version

v3.13.3

Published

Publish packages in the current project

Downloads

0

Readme

@lerna/publish

Publish packages in the current project for the current verison this is a standalone copy of publish-current-version with the version stuff removed, built specifically for running separately after lerna version when you wish to split a build pipeline

Usage

unless you are splitting out lerna version and npm publish it is unlikely you will want to use this package, in general it is a bad idea and people will shun you

publish-current-version --scope @scope/package # publish package(s) (with correct dependencies) to npm

When run, this command publishes packages specified by scope to npm with the current version

Lerna will never publish packages which are marked as private ("private": true in the package.json). (this stands true for this package)

Options

publish-current-version supports all of the options provided by lerna version in addition to the following:

--canary

publish-current-version --canary
# 1.0.0 => 1.0.1-alpha.0+${SHA} of packages changed since the previous commit
# a subsequent canary publish will yield 1.0.1-alpha.1+${SHA}, etc

publish-current-version --canary --preid beta
# 1.0.0 => 1.0.1-beta.0+${SHA}

# The following are equivalent:
publish-current-version --canary minor
publish-current-version --canary preminor
# 1.0.0 => 1.1.0-alpha.0+${SHA}

When run with this flag, publish-current-version publishes packages in a more granular way (per commit). Before publishing to npm, it creates the new version tag by taking the current version, bumping it to the next minor version, adding the provided meta suffix (defaults to alpha) and appending the current git sha (ex: 1.0.0 becomes 1.1.0-alpha.0+81e3b443).

If you have publish canary releases from multiple active development branches in CI, it is recommended to customize the --preid and --dist-tag <tag> on a per-branch basis to avoid clashing versions.

The intended use case for this flag is a per commit level release or nightly release.

--contents <dir>

Subdirectory to publish. Must apply to ALL packages, and MUST contain a package.json file. Package lifecycles will still be run in the original leaf directory. You should probably use one of those lifecycles (prepare, prepublishOnly, or prepack) to create the subdirectory and whatnot.

If you're into unnecessarily complicated publishing, this will give you joy.

publish-current-version --contents dist
# publish the "dist" subfolder of every Lerna-managed leaf package

--dist-tag <tag>

publish-current-version --dist-tag next

When run with this flag, publish-current-version will publish to npm with the given npm dist-tag (defaults to latest).

This option can be used to publish a prerelease or beta version under a non-latest dist-tag, helping consumers avoid automatically upgrading to prerelease-quality code.

Note: the latest tag is the one that is used when a user runs npm install my-package. To install a different tag, a user can run npm install my-package@prerelease.

--git-head <sha>

Explicit SHA to set as gitHead on manifests when packing tarballs, only allowed with from-package positional.

For example, when publishing from AWS CodeBuild (where git is not available), you could use this option to pass the appropriate environment variable to use for this package metadata:

publish-current-version from-package --git-head ${CODEBUILD_RESOLVED_SOURCE_VERSION}

Under all other circumstances, this value is derived from a local git command.

--no-git-reset

By default, publish-current-version ensures any changes to the working tree have been reset.

To avoid this, pass --no-git-reset. This can be especially useful when used as part of a CI pipeline in conjunction with the --canary flag. For instance, the package.json version numbers which have been bumped may need to be used in subsequent CI pipeline steps (such as Docker builds).

publish-current-version --no-git-reset

--no-verify-access

By default, lerna will verify the logged-in npm user's access to the packages about to be published. Passing this flag will disable that check.

If you are using a third-party registry that does not support npm access ls-packages, you will need to pass this flag (or set command.publish.verifyAccess to false in lerna.json).

Please use with caution

--preid

Unlike the lerna version option of the same name, this option only applies to --canary version calculation.

publish-current-version --canary
# uses the next semantic prerelease version, e.g.
# 1.0.0 => 1.0.1-alpha.0

publish-current-version --canary --preid next
# uses the next semantic prerelease version with a specific prerelease identifier, e.g.
# 1.0.0 => 1.0.1-next.0

When run with this flag, publish-current-version --canary will increment premajor, preminor, prepatch, or prerelease semver bumps using the specified prerelease identifier.

--registry <url>

When run with this flag, forwarded npm commands will use the specified registry for your package(s).

This is useful if you do not want to explicitly set up your registry configuration in all of your package.json files individually when e.g. using private registries.

--temp-tag

When passed, this flag will alter the default publish process by first publishing all changed packages to a temporary dist-tag (lerna-temp) and then moving the new version(s) to the dist-tag configured by --dist-tag (default latest).

This is not generally necessary, as Lerna will publish packages in topological order (all dependencies before dependents) by default.

--yes

publish-current-version --canary --yes
# skips `Are you sure you want to publish the above changes?`

When run with this flag, publish-current-version will skip all confirmation prompts. Useful in Continuous integration (CI) to automatically answer the publish confirmation prompt.

Per-Package Configuration

A leaf package can be configured with special publishConfig that in certain circumstances changes the behavior of publish-current-version.

publishConfig.access

To publish packages with a scope (e.g., @mycompany/rocks), you must set access:

  "publishConfig": {
    "access": "public"
  }
  • If this field is set for a package without a scope, it will fail.

  • If you want your scoped package to remain private (i.e., "restricted"), there is no need to set this value.

    Note that this is not the same as setting "private": true in a leaf package; if the private field is set, that package will never be published under any circumstances.

publishConfig.registry

You can customize the registry on a per-package basis by setting registry:

  "publishConfig": {
    "registry": "http://my-awesome-registry.com/"
  }
  • Passing --registry applies globally, and in some cases isn't what you want.

publishConfig.tag

You can customize the dist-tag on a per-package basis by setting tag:

  "publishConfig": {
    "tag": "flippin-sweet"
  }
  • Passing --dist-tag will overwrite this value.
  • This value is always ignored when --canary is passed.