With --loglevel=warn or error (or the loglevel setting), pnpm run still
printed the `$ <command>` echo before a foreground script and the summary of
the install that verifyDepsBeforeRun spawns. Both are info-level output.
Rust: expose the default reporter's configured ceiling as max_log_level(),
suppress the echo in run and run -r when it is below info (as the silent
reporter already does), and forward --loglevel=warn|error to the spawned
verify-deps install.
TypeScript: pass silent to runLifecycleHook when loglevel is silent, warn, or
error in run and runRecursive (loglevel=silent selected the silent reporter
without setting reporter, so the echo still printed), and forward those
levels through runPnpmCli to the spawned install in runDepsStatusCheck
(shared by run and exec).
Closespnpm/pnpm#8944
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
`resolvePnpmSelfCommand` decided whether `process.argv[1]` was pnpm from
its basename and the manifest above it, rejecting a script only when
another package claimed it as a bin. A script that no package claims, a
project's own `scripts/pnpm.mjs` among them, still passed.
pnpm's own code knows where it lives. The entry script is now accepted
only when its real path is the running module itself, as when a bundle
is run directly or copied elsewhere, or lies in the same package as that
module, as with `bin/pnpm.mjs` loading `dist/pnpm.mjs`. The nearest
`package.json` marks the package; the published `pnpm` and `@pnpm/exe`
tarballs carry only the one at their root. The basename set stays to keep
out hosts such as Jest, and a `pnpx` entry maps to the `pnpm.mjs` beside
it, since `pnpx` prepends `dlx` to `process.argv`. An entry that cannot
be resolved now
falls back to the pnpm on PATH, which is safe because the bundle-copy
case no longer depends on failing open.
The resolver moves to `@pnpm/cli.meta`, next to
`detectIfCurrentPkgIsExecutable`, so `npm_execpath` can share it without
`@pnpm/exec.npm-lifecycle` depending on the CLI runner. `npm_execpath`
previously took `process.argv[1]` unchecked, so a script run under
`pnpx` got `pnpx.mjs` and `$npm_execpath install` became `dlx install`.
It now gets the running pnpm's entry or executable, or the pnpm on
pnpm's own PATH when there is none, matching the runner's fallback. The `process.pkg` branch it
replaces was dead since `@pnpm/exe` moved to a Node.js SEA.
The lookup is cached for the process, since lifecycle scripts ask once
per script and neither `process.argv[1]` nor the module moves.
On Windows, `@pnpm/exe` installs `pnpx.exe` and `pnx.exe` as hardlinks
of the pnpm binary, which runs as `pnpm dlx` when launched through
either name. Re-invoking the current executable under one of them
prepended `dlx` again. Both versions now re-invoke the `pnpm` executable
beside the alias: v11 in `resolvePnpmSelfCommand` and `npm_execpath`,
and v12 through `pnpm_executor::current_pnpm_exe()` in `npm_execpath`,
`doctor`, the `verifyDepsBeforeRun` install, the pipeline agent and the
git-dependency build.
The `npm_execpath` fallback is resolved to an absolute path before a
script's PATH puts `node_modules/.bin` first, so a dependency's `pnpm`
bin cannot stand in for it.
`runPnpmCli` decided whether to re-invoke `process.argv[1]` from its
basename alone, so a script that merely carried one of pnpm's bin names
was run as if it were pnpm. The names cannot be dropped -- a Jest host's
`process.argv[1]` must not be re-executed, and `pnpx` must not be, since
that entry rewrites `process.argv` to prepend `dlx` -- so the basename
set stays as a pre-filter and the manifest above the script now decides.
The check resolves symlinks first. `process.argv[1]` keeps the name the
process was launched through, so an npm-installed pnpm arrives as
`node_modules/.bin/pn`, whose nearest manifest is the consuming
project's rather than pnpm's. Walking up without resolving would reject
a real pnpm and fall back to the PATH lookup this exists to avoid.
Only a manifest that names some other package rejects the script. An
entry with no manifest above it, a copied bundle among them, is still
pnpm as far as anything here can tell, so every filesystem failure
leaves the script trusted. The walk up only moves past a missing
`package.json`; one that exists but cannot be read ends it.
`pnpm doctor` asked the same question -- what re-invokes the pnpm
running now -- and answered it with no check at all. It now shares
`resolvePnpmSelfCommand`. Its fallback changes with that: a process
with no usable entry script gets the pnpm on PATH rather than a bare
`node`, which was never a runnable command.
`pnpm setup`'s `getExecPath` is left alone. It asks where this
executable lives so it can install from that path, not what to run.
pnpm v12 resolves its own path with `std::env::current_exe()` and has
no name-based guess to correct.
Closespnpm/pnpm#14888
Re-use process.argv[1] script when spawning pnpm CLI subprocesses via Node.js so that the invoked pnpm version is preserved (Fixes#14829).
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
The TypeScript pnpm CLI freezes at v11; pnpm 12 will be the Rust pacquet
port. To make that split legible, all TypeScript source, test, and build
directories move under a new top-level pnpm11/ directory. The name states
the version boundary rather than implying a behavioral fork, since the two
stacks are meant to behave identically.
Scope is source-only: the shared workspace root stays at the repo root.
pnpm-workspace.yaml, package.json, pnpm-lock.yaml, .pnpmfile.cjs,
.meta-updater, __patches__, .changeset, .husky, and the lint/spell configs
remain in place, so one pnpm workspace and one Cargo workspace still span
all three products. pnpr/client and pacquet/tasks/registry-mock stay as
cross-product workspace members.
Rewiring the move required:
- pnpm-workspace.yaml globs prefixed with pnpm11/
- root package.json script paths, eslint.config.mjs, tsconfig.lint.json,
.gitignore, and CODEOWNERS updated
- .meta-updater/src/index.ts literals repointed (pnpm11/pnpm/package.json,
pnpm11/__utils__, pnpm11/__typings__, and the main package directory)
- regenerated every moved package's repository/homepage URL via meta-updater
- pnpm11/pnpm/bundle-deps.ts and __utils__/scripts/src/typecheck-only.ts
climb one more level to reach the repo root
.meta-updater stays at the repo root because @pnpm/meta-updater resolves
its config at <cwd>/.meta-updater/main.mjs.
TS CI (.github/workflows/ci.yml) now only runs when pnpm11/-relevant paths
change, via a dorny/paths-filter changes job plus a TS CI / Success
aggregate gate; branch protection should require only that gate.
