privatenumber/pkgroll

^pkgroll

pkgroll is a JavaScript package bundler powered by Rollup that automatically builds your package from entry-points defined in package.json. No config necessary!

Write your code in TypeScript/ESM and run pkgroll to get ESM/CommonJS/.d.ts outputs!

Features

• ✅ package.json#exports to define entry-points
• ✅ Dependency externalization
• ✅ Minification
• ✅ TypeScript support + .d.ts bundling
• ✅ Watch mode
• ✅ CLI outputs (auto hashbang insertion)

^{Already a sponsor? Join the discussion in the Development repo!}

Install

npm install --save-dev pkgroll

Quick setup

1. Setup your project with source files in src and output in dist (configurable).

2. Define package entry-files in package.json.

   These configurations are for Node.js to determine how to import the package.

   Pkgroll leverages the same configuration to determine how to build the package.

   {
       "name": "my-package",
   
       // Set "module" or "commonjs" (https://nodejs.org/api/packages.html#type)
       // "type": "module",
   
       // Define the output files
       "main": "./dist/index.cjs",
       "module": "./dist/index.mjs",
       "types": "./dist/index.d.cts",
   
       // Define output files for Node.js export maps (https://nodejs.org/api/packages.html#exports)
       "exports": {
           "require": {
               "types": "./dist/index.d.cts",
               "default": "./dist/index.cjs",
           },
           "import": {
               "types": "./dist/index.d.mts",
               "default": "./dist/index.mjs",
           },
       },
   
       // bin files will be compiled to be executable with the Node.js hashbang
       "bin": "./dist/cli.js",
   
       // (Optional) Add a build script referencing `pkgroll`
       "scripts": {
           "build": "pkgroll",
       },
   
       // ...
   }
   

   Paths that start with ./dist/ are automatically mapped to files in the ./src/ directory.

[!TIP] In addition to package.json, pkgroll also supports pnpm's package.yaml.

3. Package roll!

   npm run build # or npx pkgroll
   

Usage

Entry-points

Pkgroll parses package entry-points from package.json by reading properties main, module, types, and exports.

The paths in ./dist are mapped to paths in ./src (configurable with the --srcdist flag) to determine bundle entry-points.

Wildcard exports

Pkgroll supports wildcard patterns in package.json#exports for exporting multiple modules with a single pattern:

{
    "exports": {
        "./utils/*": "./dist/utils/*.mjs",
        "./components/*/index": "./dist/components/*/index.mjs",
    },
}

This automatically bundles all matching source files. For example:

• src/utils/format.ts → dist/utils/format.mjs
• src/components/button/index.ts → dist/components/button/index.mjs

[!IMPORTANT] Wildcard patterns must include a file extension (e.g., .mjs, .cjs)

Subpath Imports

Pkgroll supports building entry-points defined in package.json#imports (Node.js subpath imports), including conditional imports:

{
    "imports": {
        "#my-pkg": "./dist/index.js",
        "#env": {
            "node": "./dist/env.node.js",
            "default": "./dist/env.browser.js"
        }
    }
}

Output formats

Pkgroll detects the format for each entry-point based on the file extension or the package.json property it's placed in, using the same lookup logic as Node.js.

Auto-detect infers the type by extension or package.json#type:

Bin hashbang

Entries declared in package.json#bin are made executable by prepending a hashbang and chmoding the output to 0755.

By default, the hashbang is #!/usr/bin/env node. To target a different runtime (Bun, Deno, etc.) or pass runtime flags, just write your preferred hashbang at the top of the bin's source file (e.g. src/cli.ts):

#!/usr/bin/env bun

console.log('Hello from bun!')

Hashbangs are read from the entry file only — hashbangs in imported modules are stripped (they would be invalid mid-chunk). env -S and multi-flag forms work too:

#!/usr/bin/env -S node --no-warnings

A package can mix runtimes across multiple bins. Bins without a source hashbang fall back to #!/usr/bin/env node.

Dependency bundling & externalization

Packages to externalize are detected by reading dependency types in package.json. Only dependencies listed in devDependencies are bundled in.

When generating type declarations (.d.ts files), this also bundles and tree-shakes type dependencies declared in devDependencies as well.

// package.json
{
    // ...

    "peerDependencies": {
        // Externalized
    },
    "dependencies": {
        // Externalized
    },
    "optionalDependencies": {
        // Externalized
    },
    "devDependencies": {
        // Bundled
    },
}

Aliases

Import map

You can configure aliases using the import map in package.json#imports.

In Node.js, import mappings must start with # to indicate an internal subpath import. However, Pkgroll allows defining aliases without the # prefix.

Example:

{
    "imports": {
        // Alias '~utils' points to './src/utils.js'
        "~utils": "./src/utils.js",

        // Native Node.js subpath import (must use '#', can't reference './src')
        "#internal-package": "./vendors/package/index.js",
    },
}

Tsconfig paths

You can also define aliases in tsconfig.json using compilerOptions.paths:

{
    "compilerOptions": {
        "paths": {
            "@foo/*": [
                "./src/foo/*",
            ],
            "~bar": [
                "./src/bar/index.ts",
            ],
        },
    },
}

[!TIP] The community is shifting towards using import maps (imports) as the source of truth for aliases because of their wider support across tools like Node.js, TypeScript, Vite, Webpack, and esbuild.

Target

Pkgroll uses esbuild to handle TypeScript and JavaScript transformation and minification.

The target specifies the environments the output should support. Depending on how new the target is, it can generate less code using newer syntax. Read more about it in the esbuild docs.

By default, the target is set to the version of Node.js used. It can be overwritten with the --target flag:

pkgroll --target=es2020 --target=node14.18.0

It will also automatically detect and include the target specified in tsconfig.json#compilerOptions.

Strip node: protocol

Node.js builtin modules can be prefixed with the node: protocol for explicitness:

import fs from 'node:fs/promises'

This is a new feature and may not work in older versions of Node.js. While you can opt out of using it, your dependencies may still be using it (example package using node:: path-exists).

Pass in a Node.js target that that doesn't support it to strip the node: protocol from imports:

pkgroll --target=node12.19

Custom tsconfig.json path

By default, Pkgroll looks for tsconfig.json configuration file in the current working directory. You can pass in a custom tsconfig.json path with the --tsconfig flag:

pkgroll --tsconfig=tsconfig.build.json

Export condition

Similarly to the target, the export condition specifies which fields to read from when evaluating export and import maps.

For example, to simulate import resolutions in Node.js, pass in node as the export condition:

pkgroll --export-condition=node

ESM ⇄ CJS interoperability

Node.js ESM offers interoperability with CommonJS via static analysis. However, not all bundlers compile ESM to CJS syntax in a way that is statically analyzable.

Because pkgroll uses Rollup, it's able to produce CJS modules that are minimal and interoperable with Node.js ESM.

This means you can technically output in CommonJS to get ESM and CommonJS support.

require() in ESM

Sometimes it's useful to use require() or require.resolve() in ESM. ESM code that uses require() can be seamlessly compiled to CommonJS, but when compiling to ESM, Node.js will error because require doesn't exist in the module scope.

When compiling to ESM, Pkgroll detects require() usages and shims it with createRequire(import.meta.url).

Native modules

pkgroll automatically handles native Node.js addons (.node files) when you directly import them:

// src/index.js
import nativeAddon from './native.node'

After bundling, the .node file will be copied to dist/natives/ and the import will be automatically rewritten to load from the correct location at runtime.

[!NOTE]

• Native modules are platform and architecture-specific. Make sure to distribute the correct .node files for your target platforms.
• This only works with direct .node imports. If you're using packages that dynamically load native modules via bindings or node-pre-gyp, you'll need to handle them separately.

Handling dependencies with native modules

If you're using packages with native modules (like chokidar which depends on fsevents):

• If in dependencies/peerDependencies: ✅ Works automatically - these are externalized (not bundled)
• If in devDependencies: ⚠️ Will be bundled. If they use bindings() or node-pre-gyp patterns, move them to dependencies instead, or use optionalDependencies if they're optional.

Example - if you have chokidar in devDependencies and get build errors, move it to dependencies:

{
    "dependencies": {
        "chokidar": "^3.0.0"
    }
}

This externalizes it (users will need to install it), avoiding the need to bundle its native modules.

Import attributes

Pkgroll supports import attributes for importing non-JavaScript files at build time:

// Import file contents as a string (https://github.com/tc39/proposal-import-text)
import html from './template.html' with { type: 'text' }

// Import file contents as a Uint8Array (https://github.com/tc39/proposal-import-bytes)
import bytes from './icon.png' with { type: 'bytes' }

// Also works with dynamic import
const { default: data } = await import('./data.bin', { with: { type: 'bytes' } })

The file contents are inlined into the bundle at build time, so no extra files are needed at runtime.

[!NOTE] Binary files imported with type: "bytes" are inlined as array literals, which increases bundle size (~4x for binary data). For large files, consider using dynamic import() to load them on demand.

Environment variables

Pass in compile-time environment variables with the --env flag.

This will replace all instances of process.env.NODE_ENV with 'production' and remove unused code:

pkgroll --env.NODE_ENV=production

Define

The --define flag allows you to replace specific strings in your code at build time. This is useful for dead code elimination and conditional compilation.

pkgroll --define.process.env.NODE_ENV='"production"' --define.DEBUG=false

Note: Unlike --env, values are not automatically JSON stringified, so you need to include quotes for string values.

Minification

Pass in the --minify flag to minify assets.

pkgroll --minify

Watch mode

Run the bundler in watch mode during development:

pkgroll --watch

Clean dist

Clean dist directory before bundling:

pkgroll --clean-dist

License extraction

Generate a file containing licenses for all bundled dependencies:

pkgroll --license

This collects license information from all devDependencies that are bundled into your package and writes them to a LICENSE file. This helps ensure compliance with open-source license requirements.

Custom output path

Specify a custom output file:

pkgroll --license=THIRD-PARTY-LICENSES.txt

Auto-detection

When no path is specified, pkgroll looks for existing LICENSE files (LICENSE, LICENSE.txt, LICENSE.md, LICENCE, LICENCE.txt, LICENCE.md) in your project root. If none exist, it creates a LICENSE file.

Content placement

If the LICENSE file already has a ----------- BUNDLED DEPENDENCIES ----------- marker, everything from the marker to the end of the file is replaced with the updated licenses. This preserves your project's license text above the marker.

If no marker is found, the bundled licenses (with the marker) are appended to the end of the file. Subsequent runs will find the marker and replace in-place.

[!NOTE] License extraction is skipped in watch mode since it's typically only needed for final builds.

Source maps

Pass in the --sourcemap flag to emit source map files for both JavaScript and TypeScript declaration outputs:

pkgroll --sourcemap

Or to inline them in the distribution files:

pkgroll --sourcemap=inline

Declaration source maps

For .d.ts files specifically, you can also enable source maps via declarationMap in tsconfig.json:

{
    "compilerOptions": {
        "declarationMap": true
    }
}

This enables "Go to Definition" in IDEs to navigate directly to the original .ts source files instead of the bundled .d.ts files.

Using declarationMap only generates .d.ts.map files (not .js.map), which is useful if you only need source maps for type definitions.

Filtering package.json entry points

By default, pkgroll reads all entry points from package.json (main, types, exports, bin, etc.). Use the --packagejson flag to filter which entries are built by matching against their output paths.

This is useful when your package.json has entry points that reference non-JS files (e.g. CSS modules) that would cause errors during type declaration bundling, or when you only want to build a subset of outputs.

Skip all package.json entry points (use with --input):

pkgroll --packagejson=false -i dist/index.d.mts

Filter by glob pattern on output paths:

# Only build type declarations
pkgroll --packagejson='*.d.ts'

# Only build ESM outputs
pkgroll --packagejson='*.mjs'

# Multiple patterns
pkgroll --packagejson='*.d.ts' --packagejson='*.mjs'

# Match specific files by path
pkgroll --packagejson='dist/utils.*'

Patterns without slashes match against the file basename (e.g. *.d.ts matches dist/index.d.ts). Patterns with slashes match against the full output path.

Dev vs Prod config

In some cases, it makes sense to use different package.json field values for the published environment. You can achieve this by using the publishConfig field (extended by pnpm). This allows you to override specific fields during publication with a clean separation of concerns.

The following fields can be overridden using publishConfig:

• bin
• main
• exports
• types
• module

FAQ

Why bundle with Rollup?

Rollup has the best tree-shaking performance, outputs simpler code, and produces seamless CommonJS and ESM formats (minimal interop code). Notably, CJS outputs generated by Rollup supports named exports so it can be parsed by Node.js ESM. TypeScript & minification transformations are handled by esbuild for speed.

Why bundle Node.js packages?

• ESM and CommonJS outputs

  As the Node.js ecosystem migrates to ESM, there will be both ESM and CommonJS users. A bundler helps accommodate both distribution types.

• Dependency bundling yields smaller and faster installation.

  Tree-shaking only pulls in used code from dependencies, preventing unused code and unnecessary files (eg. README.md, package.json, etc.) from getting downloaded.

  Removing dependencies also eliminates dependency tree traversal, which is one of the biggest bottlenecks.

• Inadvertent breaking changes

  Dependencies can introduce breaking changes due to a discrepancy in environment support criteria, by accident, or in rare circumstances, maliciously.

  Compiling dependencies will make sure new syntax & features are downgraded to support the same environments. And also prevent any unexpected changes from sneaking in during installation.

• Type dependencies must be declared in the dependencies object in package.json, instead of devDependencies, to be resolved by the consumer.

  This may seem counterintuitive because types are a development enhancement. By bundling them in with your package, you remove the need for an external type dependency. Additionally, bundling only keeps the types that are actually used which helps minimize unnecessary bloat.

• Minification strips dead-code, comments, white-space, and shortens variable names.

How does it compare to tsup?

They are similar bundlers, but I think the main differences are:

• pkgroll is zero-config. It reads the entry-points declared in your package.json to determine how to bundle the package. tsup requires manual configuration.

• pkgroll is a thin abstraction over Rollup (just smartly configures it). Similarly, tsup is a thin abstraction over esbuild. pkgroll also uses esbuild for transformations & minification as a Rollup plugin, but the bundling & tree-shaking is done by Rollup (which is known to output best/cleanest code). However, when tsup emits type declaration, it also uses Rollup which negates the performance benefits from using esbuild.

• IIRC because tsup uses esbuild, the ESM to CJS compilation wasn't great compared to Rollups. As a package maintainer who wants to support both ESM and CJS exports, this was one of the biggest limitations of using tsup (which compelled me to develop pkgroll).

Sponsors