Cloudflare is now backing pkg.pr.new's data infrastructure!

We call it "Continuous Releases" too.

With pkg.pr.new, each of your commits and pull requests will trigger an instant preview release without publishing anything to NPM. This enables users to access features and bug-fixes without the need to wait for release cycles using npm or pull request merges.

• 🚀 Instant Builds
• 🍕 No Need for NPM Access
• 🛠️ GitHub Workflows Friendly
• 📦️ No Configuration
• 🔩 Single Command
• ✉️ Pull Request Comments
• 🔥 Check Runs

pkg.pr.new won't publish anything to NPM; instead, it leverages its own URLs, which are npm-compatible.

npm i https://pkg.pr.new/tinylibs/tinybench/tinybench@a832a55

# npm i https://pkg.pr.new/${owner}/${repo}/${package}@{commit}

It is aiming to reduce the number of these comments :)

This was fixed in #18. Can we release that fix?

• Badge
• Setup
  • Install the GitHub App
  • Publish Packages
  • CLI Options
    • Comment Options
    • URL and Version Options
    • Template Options
    • Package Manager for Packing
  • Workflow Examples
• Custom GitHub Messages and Comments
• Who's Using pkg.pr.new

Show that your project uses pkg.pr.new by adding a badge to your README:

1. Automatically on Repository Page: Visit your repository page at https://pkg.pr.new/~/OWNER/REPO and you'll find a badge with a copy button that will copy the markdown code for you.

2. Direct Badge URL: Use this format to create a badge for your repository:

   [![pkg.pr.new](https://pkg.pr.new/badge/OWNER/REPO)](https://pkg.pr.new/~/OWNER/REPO)

   Just replace OWNER and REPO with your GitHub username/organization and repository name.

First install the GitHub Application.

After installing on your repository, run pkg-pr-new from your lockfile in workflows (for example with pnpm exec pkg-pr-new publish) to get continuous releases.

npm install --save-dev pkg-pr-new

For workspaces and monorepos:

pnpm exec pkg-pr-new publish './packages/A' './packages/B' # or `pnpm exec pkg-pr-new publish './packages/*'`

You can also pass prebuilt tarballs (.tgz or .tar.gz) directly, which is handy when your build pipeline already produces tarballs in a custom way:

pnpm exec pkg-pr-new publish './artifacts/*.tgz'

Quick reference:

--comment

You can control publishing comments with --comment:

pnpm exec pkg-pr-new publish --comment=update # default

Using --comment=update, pkg.pr.new would generate one initial comment and then edit it in the following commits.

With --comment=create, each commit would generate a comment for itself, useful for triggering workflows, like workflow execution using maintainer comments.

And --comment=off would turn off comments for maintainers who prefer minimal pull requests.

--commentWithSha

--commentWithSha specifies whether to replace the PR number with the commit SHA in the generated comments.

With --commentWithSha:

pnpm exec pkg-pr-new publish --commentWithSha

Generated comments use commit SHA URLs:

npm i https://pkg.pr.new/tinybench@a832a55

Without --commentWithSha:

pnpm exec pkg-pr-new publish

Generated comments use PR number URLs:

npm i https://pkg.pr.new/tinybench@123

--commentWithDev

--commentWithDev specify whether the generated link includes the -D parameter.

With --commentWithDev:

npm i https://pkg.pr.new/tinybench@123 -D

Without --commentWithDev:

npm i https://pkg.pr.new/tinybench@123

--packageManager

To customize which package manager is reflected in the comments, use the --packageManager=XYZ flag. XYZ can be one of the following: npm (default), pnpm, yarn, or bun. Multiple valid values can also be configured at the same time, such as --packageManager=ABC,XYZ.

--only-templates

For repositories with many packages, comments might get too long. In that case, you can use --only-templates to only show templates.

--no-compact

Compact URLs are the default (and will fall back to long form if npm metadata is unavailable). To force long-form URLs, use --no-compact:

pnpm exec pkg-pr-new publish --no-compact './packages/A' './packages/B'

Compact URLs rely on your package being published on npm with a valid repository field in package.json. See this. pkg.pr.new is case sensitive, if the GitHub owner is PuruVJ, the package.json repository field should not have puruvj.

With default compact URLs:

npm i https://pkg.pr.new/tinybench@a832a55

With --no-compact or if npm metadata is unavailable:

npm i https://pkg.pr.new/tinylibs/tinybench/tinybench@a832a55

--bin

For CLI applications you might want to show npx instead of npm i for the preview command. This can be accomplished with the --bin flag:

pnpm exec pkg-pr-new publish --bin

With --bin:

npx https://pkg.pr.new/pkg-pr-new@a832a55

Without --bin:

npm i https://pkg.pr.new/pkg-pr-new@a832a55

--previewVersion

By default, preview packages keep the version from your source package.json. That can clash with a later npm release of the same version: a lockfile may keep resolving 1.0.0 to the pkg.pr.new tarball instead of the published package.

Use --previewVersion to rewrite every published package's version to 0.0.0-preview-<sha> before packing (working tree is restored afterward):

pnpm exec pkg-pr-new publish --previewVersion './packages/*'

For example, 1.0.0 becomes 0.0.0-preview-a832a55. The 0.0.0- prefix cannot satisfy a normal semver range for a real release, so lockfile collisions with npm versions are avoided.

In monorepos, sibling dependencies / devDependencies / optionalDependencies are still rewritten to pkg.pr.new URLs as usual. With --peerDeps, cross-package peerDependencies are updated to the preview version as well.

[!NOTE] > --previewVersion only works with source directories. It is not supported when publishing prebuilt .tgz / .tar.gz inputs — rewrite the version before packing, or pass directories instead.

--template

For templates (experimental):

pnpm exec pkg-pr-new publish './packages/A' --template './examples/*'

--no-template

By default, pkg.pr.new will generate a template called "default" which includes each built package in the dependencies. This can be disabled with --no-template.

pkg.pr.new uses npm pack --json under the hood, in case you face issues, you can also use the --pnpm, --yarn, or --bun flag so it starts using pnpm pack, yarn pack, or bun pm pack. This is not necessary in most cases.

pnpm exec pkg-pr-new publish --pnpm './packages/*'

pkg.pr.new is not available in your local environment and it only works in workflows.

name: Publish Any Commit
on: [push, pull_request]

permissions: {}

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7

      - run: corepack enable
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
        with:
          node-version: 24
          cache: "pnpm"

      - name: Install dependencies
        run: pnpm install

      - name: Build
        run: pnpm build

      - run: pnpm exec pkg-pr-new publish --commentWithSha

name: Publish Approved Pull Requests
on:
  pull_request_review:
    types: [submitted]

permissions: {}

jobs:
  check:
    # First, trigger a permissions check on the user approving the pull request.
    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
    outputs:
      has-permissions: ${{ steps.checkPermissions.outputs.require-result }}
    steps:
      - name: Check permissions
        id: checkPermissions
        uses: actions-cool/check-user-permission@c21884f3dda18dafc2f8b402fe807ccc9ec1aa5e # v2
        with:
          # In this example, the approver must have the write access
          # to the repository to trigger the package preview.
          require: "write"

  publish:
    needs: check
    # Publish the preview package only if the permissions check passed.
    if: needs.check.outputs.has-permissions == 'true'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7

      - run: corepack enable
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
        with:
          node-version: 24
          cache: "pnpm"

      - name: Install dependencies
        run: pnpm install

      - run: pnpm exec pkg-pr-new publish --commentWithSha

Releasing approved pull requests is the recommended way of having continuous releases. This ensures users always install approved and safe packages.

on:
  pull_request:
  push:
    branches:
      - "**"
    tags:
      - "!**"

As noted in #140, workflows run on tags too, that's not an issue at all, but in case users would like to avoid duplicate publishes.

After pkg-pr-new publish runs successfully, some outputs are available.

• sha: The short SHA used. (E.g. a832a55)
• urls: Space-separated URLs of published packages.
• packages: Space-separated, Yarn-compatible package locators of published packages.

This is useful for using published packages in other subsequent jobs immediately after publishing. (E.g. E2E tests)

name: Publish and Test Packages
on: [push, pull_request]

permissions: {}

jobs:
  publish:
    runs-on: ubuntu-latest
    outputs:
      sha: ${{ steps.publish.outputs.sha }}
      urls: ${{ steps.publish.outputs.urls }}
    steps:
      - name: Checkout code
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7

      - run: corepack enable
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
        with:
          node-version: 24
          cache: "pnpm"

      - name: Install dependencies
        run: pnpm install

      - name: Build
        run: pnpm build

      - id: publish
        run: pnpm exec pkg-pr-new publish --commentWithSha

  e2e-test:
    runs-on: ubuntu-latest
    needs: publish
    steps:
      - name: Checkout code
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
        with:
          repository: user/my-package-e2e

      - run: corepack enable
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
        with:
          node-version: 24

      - name: Install dependencies
        run: pnpm install

      - name: Install published package
        run: pnpm add ${{ needs.publish.outputs.urls }}

      - name: Run e2e test cases
        run: # ...

For advanced use cases where you want more control over the messages posted by pkg.pr.new, you can use the --json option in combination with --comment=off. This allows you to generate metadata about the publish operation without creating a default comment, which you can then use to create custom comments via the GitHub Actions API.

1. Use pkg.pr.new with the --json and --comment=off options in your workflow:

- name: Publish packages
  run: pnpm exec pkg-pr-new publish --json output.json --comment=off

2. Add a custom step in your workflow to process the JSON output and create a custom comment:

- name: Post or update comment
  uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    script: |
      const fs = require('fs');
      const output = JSON.parse(fs.readFileSync('output.json', 'utf8'));

      const packages = output.packages
        .map((p) => `- ${p.name}: ${p.url}`)
        .join('\n');
      const templates = output.templates
        .map((t) => `- [${t.name}](${t.url})`)
        .join('\n');

      const sha =
        context.event_name === 'pull_request'
          ? context.payload.pull_request.head.sha
          : context.payload.after;

      const commitUrl = `https://github.com/${context.repo.owner}/${context.repo.repo}/commit/${sha}`;

      const body = `## Custom Publish Message

      ### Published Packages:

      ${packages}

      ### Templates:

      ${templates}

      [View Commit](${commitUrl})`;

      const botCommentIdentifier = '## Custom Publish Message';

      async function findBotComment(issueNumber) {
        if (!issueNumber) return null;
        const comments = await github.rest.issues.listComments({
          owner: context.repo.owner,
          repo: context.repo.repo,
          issue_number: issueNumber,
        });
        return comments.data.find((comment) =>
          comment.body.includes(botCommentIdentifier)
        );
      }

      async function createOrUpdateComment(issueNumber) {
        if (!issueNumber) {
          console.log('No issue number provided. Cannot post or update comment.');
          return;
        }

        const existingComment = await findBotComment(issueNumber);
        if (existingComment) {
          await github.rest.issues.updateComment({
            owner: context.repo.owner,
            repo: context.repo.repo,
            comment_id: existingComment.id,
            body: body,
          });
        } else {
          await github.rest.issues.createComment({
            issue_number: issueNumber,
            owner: context.repo.owner,
            repo: context.repo.repo,
            body: body,
          });
        }
      }

      async function logPublishInfo() {
        console.log('\n' + '='.repeat(50));
        console.log('Publish Information');
        console.log('='.repeat(50));
        console.log('\nPublished Packages:');
        console.log(packages);
        console.log('\nTemplates:');
        console.log(templates);
        console.log(`\nCommit URL: ${commitUrl}`);
        console.log('\n' + '='.repeat(50));
      }

      if (context.eventName === 'pull_request') {
        if (context.issue.number) {
          await createOrUpdateComment(context.issue.number);
        }
      } else if (context.eventName === 'push') {
        const pullRequests = await github.rest.pulls.list({
          owner: context.repo.owner,
          repo: context.repo.repo,
          state: 'open',
          head: `${context.repo.owner}:${context.ref.replace(
            'refs/heads/',
            ''
          )}`,
        });

        if (pullRequests.data.length > 0) {
          await createOrUpdateComment(pullRequests.data[0].number);
        } else {
          console.log(
            'No open pull request found for this push. Logging publish information to console:'
          );
          await logPublishInfo();
        }
      }

This custom script does the following:

• For pull requests: It creates or updates a comment with the publish information.
• For pushes with an associated open PR: It adds or updates a comment on that PR.
• For pushes without an open PR (e.g., direct pushes to main): It logs the publish information to the GitHub Actions console.

This is a sample recipe that users can adapt with --json and --comment=off to create custom comments.

This custom approach gives you full control over how pkg.pr.new communicates its results.

Publishing is only available in workflows and it supports any workflow trigger event, more information here.

These are some of the projects and companies using pkg.pr.new:

Feel free to add your project or company here to join the pkg.pr.new family :)

You can also join our discord server here, so we all have fun together!