pnpm deploy

Розгортає пакунок з робочої області. Під час розгортання файли пакунка копіюються в цільову теку. Усі залежності розгорнутого пакунка, включно з залежностями з робочої області, встановлюються всередині ізольованої теки node_modules цільової теки. Цільова тека міститиме переносимий пакунок, який можна скопіювати на сервер і виконати без додаткових кроків.

нотатка

Since v12.2.0, pnpm deploy no longer requires injectWorkspacePackages. A linked workspace dependency is rewritten to a file: dependency in the dedicated deploy lockfile. The peer dependencies it declares are bound the way an injected install binds them: to the version its parent provides. If the parent does not depend on the peer, pnpm looks further up, to the deployed project. A peer that no ancestor provides is bound to the deployed graph's own resolution.

The binding is ambiguous when the ancestors provide more than one package or version, or when no ancestor provides the peer and the deployed graph holds more than one version. The deploy then fails with ERR_PNPM_DEPLOY_AMBIGUOUS_PEER, naming the package, the peer, and the competing resolutions. Pin the peer to one version with an overrides entry, or turn injectWorkspacePackages on, which is the setting that decides between the candidates.

Before v12.2.0, the command refused every non-injected workspace up front. --legacy, or forceLegacyDeploy: true, still selects the older implementation.

нотатка

Коли встановлено опцію enableGlobalVirtualStore, pnpm deploy ігнорує її та завжди створює локалізоване віртуальне сховище в теці розгортання. Це дозволяє зберегти теку розгортання автономною та переносною.

Використання:

pnpm --filter=<deployed project name> deploy <target directory>

The filter must select exactly one project. Selecting none fails with ERR_PNPM_NOTHING_TO_DEPLOY, and selecting several fails with ERR_PNPM_CANNOT_DEPLOY_MANY. A target directory that is unsafe to write, such as the workspace root, fails with ERR_PNPM_INVALID_DEPLOY_TARGET.

Якщо ви створюєте свій проєкт перед розгортанням, також використовуйте параметр --prod, щоб пропустити встановлення devDependencies.

pnpm --filter=<deployed project name> --prod deploy <target directory>

Використання в образі docker. Після створення всього у вашому монорепо, зробіть це у другому образі, який використовує ваш базовий образ монорепо як контекст збірки, або на додатковій стадії збирання:

Dockerfile
# syntax=docker/dockerfile:1.4

# The workspace image must use WORKDIR /app
FROM workspace as pruned
RUN pnpm --filter <your package name> --prod deploy pruned

FROM node:22-alpine
WORKDIR /app

ENV NODE_ENV=production

COPY --from=pruned /app/pruned .

ENTRYPOINT ["node", "index.js"]

A deployed symlink to a directory inside the project is kept even if the directory is not deployed. So is a symlink to a missing path inside the project, such as a link into a removed node_modules. A link into node_modules resolves to the dependency installed in the output directory. A symlink to a file that is not deployed is replaced by a copy of the file.

To deploy without registry metadata, keep the source lockfile and populate the store with pnpm install or pnpm fetch before running pnpm deploy --offline. This also works with per-project lockfiles and --legacy. Use --trust-lockfile if deployment should skip supply-chain policy checks on the locked dependencies. New or changed dependencies may still require registry metadata.

Параметри#

pnpm deploy accepts the options of pnpm install for the install it runs into the target directory.

--force#

Allow deployment to a non-empty target directory. Without this flag, pnpm fails with ERR_PNPM_DEPLOY_DIR_NOT_EMPTY if the target directory is not empty.

--ignore-scripts#

Skip lifecycle scripts during deployment, including dependency build scripts. See pnpm install --ignore-scripts.

--dev, -D#

Встановлюються лише devDependencies.

--no-optional#

optionalDependencies не буде встановлено.

--prod, -P#

Пакунки з devDependencies не будуть встановлені.

--filter <package_selector>#

Читайте більше про фільтрування.

--legacy#

Використовувати історичну реалізацію розгортання.

Стандартно, pnpm deploy спробує створити спеціальний файл блокування зі спільного файлу блокування для розгортання. The --legacy flag disables this behavior.

Since v12.4.1, the legacy implementation prefers the versions the source workspace lockfile pins, wherever they still satisfy the deployed project's ranges.

Since v12.16.0, it checks the source workspace lockfile against minimumReleaseAge and the other resolution policies first, as pnpm install does, and fails if one of them rejects a locked version. trustLockfile or --trust-lockfile skips that check.

What the deployed project gets#

  • The packageManager and devEngines.packageManager fields of the workspace root package.json are not copied into the deployed package.json.
  • The virtual store is placed at virtualStoreDir, resolved against the deploy directory. With the global virtual store enabled or an absolute virtualStoreDir, it stays at node_modules/.pnpm.
  • The prepare script of the deployed project is not run.
  • A workspace project that the deploy installs as a file: dependency runs its build scripts. pnpm approves it by its dependency path in the allowBuilds setting. An allowBuilds entry that denies the project still applies.
  • A workspace project with publishConfig.directory is installed from that directory. Its build scripts run only if the directory is inside the project and not inside node_modules.

Reproducible output#

Since v12.15.0, when the SOURCE_DATE_EPOCH environment variable is set, pnpm deploy and pnpm install use it as an upper bound for the timestamps in node_modules/.modules.yaml and node_modules/.pnpm-workspace-state-v1.json. With an equivalently prepared deploy target and an epoch no later than the timestamps that would otherwise be recorded, deploying the same project with the same lockfile produces identical files, so a Docker layer built from the deploy directory stays cached.

The next pnpm install or pnpm run in that directory checks the installed dependencies against the lockfile instead of trusting file modification times.

Файли, включені в розгорнутий проєкт#

By default, pnpm copies the files that pnpm pack would include. They are selected in one of the following ways, resolved in order:

  1. У файлі package.json проєкту може бути поле "files", яке містить список файлів та тек, які повинні бути скопійовані.
  2. Якщо у теці застосунку є файл .npmignore, то всі файли, перелічені в ньому, ігноруються.
  3. Якщо у теці застосунку є файл .gitignore, то всі файли, перелічені в ньому, ігноруються.

To copy every file of the project, set deployAllFiles to true.

Налаштування#

forceLegacyDeploy#

  • Стандартно: false
  • Тип: Boolean

Стандартно, pnpm deploy спробує створити спеціальний файл блокування зі спільного файлу блокування для розгортання. Якщо цей параметр встановлено у значення true, буде використано успадковану поведінку deploy.