deno publish

deno publish publishes your package to the JSR registry.

Package Requirements

Your package must have a name and version and an exports field in its deno.json or jsr.json file.

The name field must be unique and follow the @<scope_name>/<package_name> convention.
The version field must be a valid semver version. To bump it as part of your release flow, see deno bump-version.
The exports field must point to the main entry point of the package. The exports field can either be specified as a single string, or as an object mapping entrypoint names to paths in your package.

Example:

deno.json

{
  "name": "@scope_name/package_name",
  "version": "1.0.0",
  "exports": "./main.ts"
}

Before you publish your package, you must create it in the registry by visiting JSR - Publish a package.

Excluding a workspace member

When run inside a workspace, deno publish tries to publish every member that has a name and exports, and errors if any of them is missing a version. To opt a member out, for example an internal helper package that only exists to host shared tasks, set "publish": false in that member's deno.json:

internal-helpers/deno.json

{
  "name": "@scope/internal-helpers",
  "publish": false
}

The member stays part of the workspace but is skipped by deno publish. See Excluding a workspace member from publish for the full discussion.

Examples

Publish your current workspace

›_

deno publish

Publish your current workspace with a specific token, bypassing interactive authentication

›_

deno publish --token c00921b1-0d4f-4d18-b8c8-ac98227f9275

Publish and check for errors in remote modules

›_

deno publish --check=all

Perform a dry run to simulate publishing.

›_

deno publish --dry-run

Publish using settings from a specific configuration file

›_

deno publish --config custom-config.json

Command line usage:

deno publish [OPTIONS]

Publish the current working directory's package or workspace to JSR

Publishing options

--allow-dirty

Allow publishing if the repository has uncommitted changed.

--allow-slow-types

Allow publishing with slow types.

--dry-run

Prepare the package for publishing performing all checks and validations without uploading.

--no-provenance

Disable provenance attestation. Enabled by default on Github actions, publicly links the package to where it was built and published from.

--set-version<VERSION>

Set version for a package to be published. This flag can be used while publishing individual packages and cannot be used in a workspace.

--token<token>

The API token to use when publishing. If unset, interactive authentication is be used.

Options

--config, -c<FILE>

Configure different aspects of deno including TypeScript, linting, and code formatting. Typically the configuration file will be called deno.json or deno.jsonc and automatically detected; in that case this flag is not necessary.

--env-file<FILE>optional

Load environment variables from local file Only the first environment variable with a given key is used. Existing process environment variables are not overwritten, so if variables with the same names already exist in the environment, their values will be preserved. Where multiple declarations for the same environment variable exist in your .env file, the first one encountered is applied. This is determined by the order of the files you pass as arguments.

--no-config

Disable automatic loading of the configuration file.

Type checking options

--check<CHECK_TYPE>optional

Set type-checking behavior. This subcommand type-checks local modules by default, so passing --check is redundant; pass --check=all to also type-check remote modules. Alternatively, use the 'deno check' subcommand.

--no-check<NO_CHECK_TYPE>optional

Skip type-checking. If the value of "remote" is supplied, diagnostic errors from remote modules will be ignored.