Skip to main content
The deno publish command publishes your package to JSR, the JavaScript Registry.

​
Usage

deno publish [OPTIONS]

​
Description

Publishes packages to JSR. This command handles the entire publishing workflow:
  • Validates your package configuration
  • Runs fast check (by default) to ensure public APIs are well-typed
  • Creates and uploads a tarball to JSR
  • Optionally generates provenance for supply chain security
The command looks for packages to publish in your workspace based on deno.json or jsr.json configuration files.

​
Options

​
--token
string
Authentication token for JSR. If not provided, the command will prompt for interactive authentication.
​
--dry-run
boolean
default:"false"
Prepare the package but don’t actually publish it. Useful for testing.
​
--allow-slow-types
boolean
default:"false"
Allow publishing with slow types. By default, the command ensures all public APIs use fast check compatible types for better performance.
​
--allow-dirty
boolean
default:"false"
Allow publishing with uncommitted changes in the git repository.
​
--no-provenance
boolean
default:"false"
Skip generating provenance. By default, provenance is generated on GitHub Actions with OIDC token.
​
--set-version
string
Set the version to publish. Cannot be used when publishing a workspace with multiple packages.

​
Package Configuration

Your deno.json must include: 
{
  "name": "@scope/package-name",
  "version": "1.0.0",
  "exports": "./mod.ts"
}

​
Required Fields

  • name: Package name in the format @scope/package-name
  • version: Semantic version of the package
  • exports: Entry point(s) for the package

​
Optional Fields

{
  "name": "@scope/package-name",
  "version": "1.0.0",
  "exports": {
    ".": "./mod.ts",
    "./utils": "./utils.ts"
  },
  "publish": {
    "include": ["**/*.ts", "README.md"],
    "exclude": ["**/*_test.ts"]
  },
  "license": "MIT"
}

​
Examples

​
Publish a package (interactive auth)

deno publish

​
Dry run to test publishing

deno publish --dry-run

​
Publish with a token

deno publish --token=<your-token>

​
Publish allowing slow types

deno publish --allow-slow-types

​
Publish with uncommitted changes

deno publish --allow-dirty

​
Set version during publish

deno publish --set-version 2.0.0

​
Publish workspace packages

For a monorepo with multiple packages: 
deno publish
This will publish all packages in the workspace in dependency order.

​
Publishing Workflow

  1. Configuration Check: Validates deno.json has required fields
  2. File Collection: Gathers files based on publish.include and publish.exclude
  3. Type Checking: Runs fast check on public APIs (unless --allow-slow-types)
  4. Graph Analysis: Ensures no excluded modules or invalid imports
  5. Git Check: Verifies no uncommitted changes (unless --allow-dirty)
  6. Scope/Package Check: Ensures scope and package exist on JSR
  7. Tarball Creation: Creates a gzipped tarball of the package
  8. Upload: Uploads to JSR with authentication
  9. Provenance: Generates and submits provenance (if on GitHub Actions)

​
Fast Check

By default, Deno enforces “fast check” for published packages. This ensures:
  • Public APIs are fully typed
  • Types can be checked without executing code
  • Better performance for package consumers
  • Automatic .d.ts file generation for Node.js users
To bypass this requirement: 
deno publish --allow-slow-types
Note: This is not recommended as it may lead to poor type checking performance for users.

​
Provenance

When publishing from GitHub Actions with OIDC token support, Deno automatically generates provenance:
  • Creates a signed attestation of the package
  • Publishes to Sigstore transparency log
  • Provides supply chain security guarantees
To disable: 
deno publish --no-provenance

​
Environment Variables

​
DENO_TESTING_DISABLE_GIT_CHECK
boolean
Skip git dirty check (for testing only).
​
DISABLE_JSR_PROVENANCE
boolean
Disable provenance generation.

​
Notes

  • The first time you publish a scope or package, you’ll need to create it on JSR first
  • Packages are immutable once published - you cannot unpublish or modify a published version
  • Version numbers must follow semantic versioning
  • Package names must be lowercase and can contain letters, numbers, and hyphens

Build docs developers (and LLMs) love

Get started for freeTalk to us