Переход с pnpm

pnpm — это менеджер пакетов, а не среда выполнения, поэтому большая часть того, что вы «переносите», — это конфигурация, а не код. Deno читает ваш существующий package.json, устанавливает те же зависимости npm и запускает ваши скрипты, поэтому проект pnpm с одним пакетом обычно вообще не требует изменений.

Единственное отличие pnpm от npm, Yarn и Bun — место хранения конфигурации рабочих пространств. npm, Yarn и Bun хранят шаблоны рабочих пространств в package.json в workspaces, откуда Deno считывает их напрямую. pnpm хранит их в отдельном файле pnpm-workspace.yaml. Deno не читает этот файл при разрешении зависимостей, но автоматически переносит его при первой необходимости, как описано ниже.

Запуск проекта

Установите зависимости и запустите точку входа:

›_

cd my-pnpm-app
deno install
deno run main.ts

deno install читает ваш существующий package.json и разрешает те же npm-пакеты, например pnpm install. Он создаёт каталог node_modules и собственный deno.lock.

При первом запуске deno install, если файла deno.lock ещё нет, Deno создаёт его на основе вашего существующего pnpm-lock.yaml: уже зафиксированные версии и хеши целостности сохраняются, поэтому при переходе вас не ждёт неожиданный раунд обновлений. Структура node_modules тоже покажется знакомой: как и pnpm, Deno использует изолированную структуру, в которой каждый пакет видит только объявленные для него зависимости.

Скрипты, заданные в package.json, запускаются с помощью deno task — аналога pnpm run:

›_

deno task dev

Если вы также переходите с запуска приложения в Node на запуск в Deno, сразу заметите одно отличие: по умолчанию Deno работает в песочнице. При первом обращении программы к сети, файловой системе или переменным окружения Deno запрашивает разрешение. Чтобы поведение соответствовало Node, сразу предоставьте все разрешения с помощью deno run -A main.ts, а затем при необходимости сузьте набор флагов. Подробнее см. в разделе Безопасность и разрешения.

Шпаргалка по переходу с pnpm на Deno

Зависимости

pnpm	Deno
`pnpm install`	`deno install`
`pnpm add <pkg>`	`deno add <pkg>`
`pnpm add -D <pkg>`	`deno add -D <pkg>`
`pnpm remove <pkg>`	`deno remove <pkg>`
`pnpm update`	`deno update`
`pnpm outdated`	`deno outdated`
`pnpm install --frozen-lockfile`	`deno ci`
`pnpm audit`	`deno audit`
`pnpm why <pkg>`	`deno why <pkg>`

Запуск и выполнение

pnpm	Deno
`pnpm <script>`	`deno task <script>`
`pnpm run <script>`	`deno task <script>`
`pnpm dlx <pkg>`	`dx <pkg>`
`pnpm exec <cmd>`	`deno task <cmd>`

В отличие от pnpm, Deno также поставляется со встроенными форматировщиком и линтером, поэтому deno fmt и deno lint заменяют Prettier, ESLint или Biome без дополнительных зависимостей.

Рабочие пространства и pnpm-workspace.yaml

npm, Yarn и Bun хранят шаблоны рабочих пространств в package.json, а pnpm хранит их в отдельном файле pnpm-workspace.yaml, который Deno не читает при разрешении зависимостей. Вам не нужно преобразовывать этот файл вручную: если участник рабочего пространства или версия из каталога не разрешаются из-за его содержимого, Deno находит расположенный рядом файл pnpm-workspace.yaml, преобразует его поля packages, catalog и catalogs в эквивалентные поля конфигурации Deno и выводит подсказку:

warning: Found pnpm-workspace.yaml nearby, which Deno does not read directly.
hint: Migrated its workspace configuration into package.json. Run the command again.

Запустите ту же команду ещё раз — теперь она выполнится без проблем. После переноса шаблоны рабочих пространств будут храниться в массиве workspace, эквивалентном списку packages в pnpm:

pnpm-workspace.yaml (до переноса)

packages:
  - "packages/*"
  - "apps/*"

deno.json (после переноса)

{
  "workspace": ["packages/*", "apps/*"]
}

При чтении перенесённых шаблонов стоит учитывать несколько отличий:

В Deno глубина задаётся явно. packages/* соответствует одному уровню (packages/foo), а packages/*/* — двум. Рекурсивного шаблона ** нет; вместо него добавляйте сегмент /* для каждого уровня. См. раздел Шаблоны путей рабочих пространств.
Исключения не поддерживаются. Отрицание !packages/excluded в pnpm не имеет эквивалента в поле workspace, поэтому явно перечислите нужных участников, а не исключайте несколько из шаблона.

Каталоги

Каталоги pnpm позволяют использовать общие версии зависимостей в разных участниках, и Deno поддерживает тот же протокол catalog: (добавлен в Deno 2.8). Автоматический перенос перемещает определения каталогов в корневой файл deno.json, используя те же имена полей:

deno.json

{
  "workspace": ["packages/*"],
  "catalog": {
    "react": "^19.0.0"
  },
  "catalogs": {
    "react18": {
      "react": "^18.3.0"
    }
  }
}

Ссылки catalog: в package.json каждого участника остаются без изменений: "react": "catalog:" разрешается в каталог catalog по умолчанию, а "react": "catalog:react18" — в именованную запись в catalogs. См. раздел Централизованные версии зависимостей с помощью catalog:.

Что не имеет прямого аналога

Некоторые настройки pnpm-workspace.yaml относятся только к pnpm и не имеют аналога в Deno. Учитывайте это при планировании, а не пытайтесь их перенести:

overrides. Принудительно задайте для транзитивной зависимости определённую версию с помощью разрешения npm:, которое уже использует ваш проект, или добавьте запись в карту импортов.
patchedDependencies. В Deno нет встроенного механизма, аналогичного patch-package. Вендорьте зависимость или поддерживайте патч в собственном форке.
registries, packageExtensions и аналогичные настройки. Они предназначены специально для настройки резолвера pnpm и не переносятся.

Что дальше

Переход с npm. Процессы работы с CLI npm и pnpm соответствуют тем же командам Deno.
Переход с Node.js. Если вы также переходите на другую среду выполнения, в этом разделе рассматриваются разрешение CommonJS и ES-модулей, а также встроенные модули Node, поддерживаемые Deno.
Рабочие пространства. Подробно о том, как Deno разрешает участников, общие импорты и каталоги.
Управление зависимостями. Процессы работы с npm, JSR и package.json.
Управление цепочкой поставок. deno audit, правила работы с lock-файлом и минимальный возраст зависимости.