cli commands/pack

18 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

deno pack command basic usage

The `deno pack` command builds an npm-compatible tarball (.tgz) from a Deno project for publishing to npm. It transpiles TypeScript to JavaScript, generates .d.ts declaration files, rewrites import specifiers, and synthesizes a package.json. The basic command is `deno pack` with no arguments.

deno pack reads from deno.json

deno pack reads the package metadata from deno.json, specifically the name, version, and exports fields, and writes a gzipped tarball to the current directory.

deno pack output filename convention

deno pack produces a tarball with the filename derived from the package name and version in deno.json, with @ symbols stripped and / replaced with -, matching npm pack's naming convention. For example, '@scope/my-lib' version '1.0.0' produces 'scope-my-lib-1.0.0.tgz'.

deno pack tarball contents

The tarball produced by deno pack contains: a generated package.json with name, version, type: 'module', conditional exports (types/import/default), and a dependencies field derived from jsr:/npm: imports; transpiled .js files with inline source maps by default; generated .d.ts declaration files; and README and LICENSE files from the project root if present. Only files reachable through the module graph from exports are included.

deno pack specifier rewriting

deno pack rewrites import specifiers during transpilation as follows: jsr:@std/path becomes @jsr/std__path in the tarball (consumers need the JSR npm registry configured); npm:express@4 becomes express with the version moved into dependencies in package.json; ./utils.ts becomes ./utils.js (extension only, no path restructuring); node:fs remains unchanged.

deno pack Deno API shimming

If code uses the Deno.* global, deno pack automatically adds @deno/shim-deno as a runtime dependency and injects the shim so the package can run under Node.js. The shim covers the subset of Deno.* that maps cleanly onto Node APIs. Pass --no-deno-shim to opt out.

deno pack --set-version flag

Pass `deno pack --set-version 2.0.0-rc.1` to override the version from deno.json, useful when releasing a one-off prerelease without editing deno.json.

deno pack --output flag

Pass `deno pack --output dist/my-package.tgz` to specify a custom output path for the tarball.

deno pack --dry-run flag

Pass `deno pack --dry-run` to preview what would be in the tarball without actually producing one. This prints the contents that would be included and is handy in CI to verify file inclusion rules.

deno pack --allow-slow-types flag

Slow types prevent .d.ts generation. Pass `deno pack --allow-slow-types` to pack anyway; the tarball will not include declaration files.

deno pack --no-deno-shim flag

Pass `deno pack --no-deno-shim` to skip automatic Deno API shimming, useful if you've already provided your own abstraction or only intend the package to run under Deno-on-npm.

deno pack --allow-dirty flag

Pass `deno pack --allow-dirty` to pack despite a dirty git working tree. By default, deno pack refuses to pack when the git working tree has uncommitted changes, to make releases reproducible from the commit hash.

deno pack --ignore flag

Pass `deno pack --ignore=tests/ --ignore='**/*.test.ts'` to exclude files. --ignore accepts glob patterns and can be combined multiple times to add patterns.

deno pack --no-source-maps flag

Pass `deno pack --no-source-maps` to omit inline source maps from emitted .js files, resulting in smaller tarballs but harder debugging upstream. By default, source maps are inlined.

deno pack positional arguments for non-JS assets

Non-JS assets such as data files or WASM are only included in the tarball if they're imported from JS/TS. To ship arbitrary files, list them as positional arguments: `deno pack assets/icon.svg locales/*.json`.

deno pack workspace support

In a workspace, deno pack runs against the current working directory's member. To pack a specific member from the root, change to that directory: `cd packages/my-lib && deno pack`. Cross-workspace npm:/jsr: dependencies are rewritten in the generated package.json to point at their published versions, not to other workspace members.

deno pack limitations

deno pack has these limitations: No bin entries (does not synthesize the package.json bin field; library publishing is supported but CLI tools still need a hand-rolled npm package); No native addons (packages that link against native code are out of scope); No .npmignore (use --ignore for excludes; .gitignore is honored); No lifecycle scripts (prepublishOnly/prepare/postinstall hooks are not run because package.json is generated, not read).

deno pack vs deno publish comparison

Use deno publish to release to JSR. Use deno pack to release to npm with `deno pack` followed by `npm publish ./*.tgz`. deno pack rewrites JSR imports for npm consumers without forcing JSR setup. A library can ship to both by releasing to JSR with deno publish, then building and pushing a tarball to npm with deno pack for users who haven't adopted JSR yet.

Give your agent this brain