Two changes that let a CI job reuse a past lockfile verification. `pnpm store prune` kept deleting `lockfile-verified.jsonl` in the TypeScript CLI, for a cosmetic reason: a record written under a different policy or lockfile looked like an alien file in `cacheDir`. It is not one — the record is keyed on the lockfile content and the policy snapshot, and a stale one is simply never trusted. Deleting it costs the next install a full re-verification against the registry, which is the dominant cost of an install in CI: 16.6s of a 17.6s install on Linux and 40.1s of 42.4s on Windows in typescript-eslint's repository. The Rust CLI already kept it. `pnpm cache path` prints the resolved cache directory, mirroring `pnpm store path`. pnpm derives that directory from the platform and the `cacheDir` setting and never reported it, so callers that want to cache or inspect it — `pnpm/setup` and `pnpm/action-setup` among them — had to mirror the resolution by hand. Both stacks print it absolute and lexically cleaned, so a relative `cacheDir` yields a path other tools can consume; symlinks are left alone so macOS does not print a path that differs from the configuration.
23 lines
691 B
TypeScript
23 lines
691 B
TypeScript
import path from 'node:path'
|
|
|
|
import { expect, test } from '@jest/globals'
|
|
import { cache } from '@pnpm/cache.commands'
|
|
|
|
test('print the cache directory', async () => {
|
|
const cacheDir = path.resolve('cache')
|
|
// The printed path is handed to other tools, so it is cleaned of `.` and
|
|
// `..` segments rather than echoed back as configured.
|
|
const configuredCacheDir = [cacheDir, '..', '.', 'cache'].join(path.sep)
|
|
|
|
const result = await cache.handler({
|
|
cacheDir: configuredCacheDir,
|
|
cliOptions: {},
|
|
pnpmHomeDir: '',
|
|
registrySupportsTimeField: false,
|
|
resolutionMode: 'highest',
|
|
storeDir: path.resolve('store'),
|
|
}, ['path'])
|
|
|
|
expect(result).toBe(cacheDir)
|
|
})
|