@catladder/cli 0.0.0-next-1d12aca2 → 0.0.0-next-cf4e99eb

package/dist/bundles/catenv/index.js

@@ -6096,11 +6096,14 @@ const createNodeDockerJobDefinition = async (context) => {
         (0, packageManagerInstall_1.getDockerAppCopyAndBuildScript)(context),
         context.packageManagerInfo,
     ]);
-    // the pnpm store (pulled via the cache above) is copied into the
-    // image so the prod install works offline — like the yarn zip cache,
-    // which travels inside the copied `.yarn` config folder
-    const copyPnpmStore = packageManagerInfo.type === "pnpm" &&
-        packageManagerInfo.componentIsInWorkspace;
+    // The pnpm store is deliberately NOT copied into the image. It used
+    // to be, so the prod install could link instead of hitting the
+    // registry — but the store lands in an earlier layer than
+    // node_modules, so pnpm cannot hardlink across the overlay boundary
+    // and copies every package instead. Measured on one component: the
+    // in-image install was *slower* that way (28s vs 10s from the
+    // registry), the store added 3GB to the build context and the final
+    // image, and the build took 339s instead of 27s.
     // pnpm copies every workspace manifest into the image — as individual
     // COPY instructions that many layers exceed docker's depth limit, so
     // the job tars them up and a single ADD extracts them
@@ -6108,8 +6111,6 @@ const createNodeDockerJobDefinition = async (context) => {
     const WORKSPACE_FILES_TAR = ".catladder-workspace-files.tar";
     return {
         script: [
-            // the COPY source must exist even when the cache was cold
-            ...(copyPnpmStore ? ["mkdir -p .pnpm-store"] : []),
             ...(isPnpm
                 ? [
                     `tar -cf ${WORKSPACE_FILES_TAR} ${packageManagerInfo.pathsToCopyInDocker.join(" ")}`,
@@ -6126,14 +6127,10 @@ const createNodeDockerJobDefinition = async (context) => {
                     `ADD ${WORKSPACE_FILES_TAR} /app/`,
                     // ADD does not apply --chown to extracted tars, and parent
                     // dirs of the entries come out root-owned — fix ownership
-                    // while the stage still runs as root (store not copied yet,
-                    // so this only touches the small manifest tree). Custom
-                    // base images without a node user run as root and don't
-                    // need it, hence the fallback
+                    // while the stage still runs as root (this only touches the
+                    // small manifest tree). Custom base images without a node
+                    // user run as root and don't need it, hence the fallback
                     `RUN chown -R node:node /app || true`,
-                    ...(copyPnpmStore
-                        ? [`COPY --chown=node:node .pnpm-store /app/.pnpm-store`]
-                        : []),
                 ].join("\n")
                 : packageManagerInfo.pathsToCopyInDocker
                     .map((dir) => `COPY --chown=node:node ${dir} /app/${dir}`)
@@ -6167,10 +6164,9 @@ const lodash_es_1 = __nccwpck_require__(50210);
 const path_1 = __nccwpck_require__(16928);
 const slugify_1 = __importDefault(__nccwpck_require__(84007));
 /**
- * stable reference between the two node caches: the package-manager
- * (yarn zip / pnpm store) cache declares itself redundant when the
- * node_modules cache scored an exact-lockfile hit (github skips the
- * ~0.6GB download on warm runs)
+ * stable reference between the two yarn caches: the zip cache declares
+ * itself redundant when the node_modules cache scored an exact-lockfile
+ * hit (github skips the ~0.6GB download on warm runs)
  */
 const NODE_MODULES_CACHE_ID = "node-modules";
 /**
@@ -6198,36 +6194,36 @@ const getCacheBaseDir = async (context) => {
         : ".";
 };
 /**
- * the package manager's download cache: yarn's `.yarn` zip cache, or
- * pnpm's content-addressable store (which catladder points at a
- * project-local `.pnpm-store`, see the install script)
+ * the package manager's download cache: yarn's `.yarn` zip cache.
+ *
+ * pnpm gets nothing. Its store is a content-addressable tree of
+ * hundreds of thousands of small files, and moving it costs more than
+ * the install it saves: measured on a 3800-package monorepo, restoring
+ * the 1 GB store took ~53s on gitlab (which zips file by file) and
+ * ~23s on github, against a from-registry install of ~30-40s. See
+ * getNodeModulesCache for the node_modules half of the same finding.
  */
 const getYarnCache = async (context, policy = "pull-push") => {
     const packageManagerInfo = await context.packageManagerInfo;
-    const isPnpm = packageManagerInfo.type === "pnpm";
+    if (packageManagerInfo.type === "pnpm")
+        return [];
     const baseDir = await getCacheBaseDir(context);
-    // pnpm keeps its store in a format-versioned subdir (v10, v11, ...)
-    // and never cleans old ones up — scope the cache slot by major so a
-    // pnpm upgrade starts a fresh slot instead of dragging the dead old
-    // store tree along in every cache transfer (formats change only on
-    // majors)
-    const pnpmStoreKey = `pnpm-v${packageManagerInfo.version.split(".")[0]}`;
     return [
         {
             scope: "buildDir",
             pathMode: "relative",
             buildDir: baseDir,
-            key: isPnpm ? pnpmStoreKey : "yarn",
+            key: "yarn",
             policy,
-            paths: [isPnpm ? ".pnpm-store" : ".yarn"],
+            paths: [".yarn"],
             // content-key for immutable-cache backends (github); the lockfile
             // decides whether the cached content could have changed
-            keyFiles: [isPnpm ? "pnpm-lock.yaml" : "yarn.lock"],
-            // the package manager's download cache (~hundreds of MB) is only
-            // read when packages have to be (re)installed. When the
-            // node_modules cache hit for the same lockfile, install verifies
-            // its state file and never touches the store — so github skips
-            // downloading this cache entirely
+            keyFiles: ["yarn.lock"],
+            // the yarn zip cache (~hundreds of MB) is only read when packages
+            // have to be (re)installed. When the node_modules cache hit for
+            // the same lockfile, install verifies its state file and never
+            // touches the zips — so github skips downloading this cache
+            // entirely
             redundantOnExactHitOf: NODE_MODULES_CACHE_ID,
         },
     ];
@@ -6236,12 +6232,18 @@ exports.getYarnCache = getYarnCache;
 const getNodeModulesCache = async (context, policy = "pull-push") => {
     const packageManagerInfo = await context.packageManagerInfo;
     const baseDir = await getCacheBaseDir(context);
-    const { workspaces } = packageManagerInfo;
-    const isPnpm = packageManagerInfo.type === "pnpm";
-    const lockFileName = isPnpm ? "pnpm-lock.yaml" : "yarn.lock";
-    // yarn berry tracks install state in .yarn/install-state.gz (pnpm's
-    // equivalent lives inside node_modules and is covered by the paths)
-    const hasInstallState = packageManagerInfo.type === "yarn" && !packageManagerInfo.isClassic;
+    // pnpm gets no node_modules cache either: archiving the tree (root
+    // plus every workspace's symlink farm, >1GB in real monorepos) costs
+    // ~190s per saving job to spare ~6s of install, and a safe pnpm slot
+    // must be keyed by lockfile hash (a pnpm install over a node_modules
+    // from a different lockfile leaves orphaned .pnpm dirs that break
+    // type identity), so it misses on every dependency change anyway.
+    // pnpm projects run entirely uncached — see getYarnCache
+    if (packageManagerInfo.type === "pnpm")
+        return [];
+    const lockFileName = "yarn.lock";
+    // yarn berry tracks install state in .yarn/install-state.gz
+    const hasInstallState = !packageManagerInfo.isClassic;
     // We intentionally do not use the contents of the lockfile as a cache key, as install should always guarantee that the files are updated, but it can still use part of the cache if not all packages are up-to-date.
     // It would slow down all pipelines whenever one adds a new dependency as it will need to download all node_modules again.
     return [
@@ -6249,19 +6251,7 @@ const getNodeModulesCache = async (context, policy = "pull-push") => {
             scope: "global",
             pathMode: "absolute",
             // we use the dirname, not the component name, because in certain cases we have two apps in the same directory and want to share the cache, e.g. when having storybook in the same package.json
-            //
-            // pnpm gets its own, lockfile-keyed cache: node_modules layouts
-            // are not compatible between package managers (a migrating
-            // project must not inherit the yarn slot), and unlike yarn, a
-            // pnpm install on top of a node_modules from a different lockfile
-            // leaves orphaned .pnpm dirs behind that break type identity —
-            // so the slot changes whenever the lockfile changes
-            key: isPnpm
-                ? {
-                    prefix: "pnpm-" + (0, slugify_1.default)(baseDir) + "-node-modules",
-                    files: [(0, path_1.join)(baseDir, "pnpm-lock.yaml")],
-                }
-                : (0, slugify_1.default)(baseDir) + "-node-modules",
+            key: (0, slugify_1.default)(baseDir) + "-node-modules",
             // content-key for immutable-cache backends (github); the lockfile
             // decides whether the cached content could have changed (absolute
             // pathMode: resolve the lockfile explicitly)
@@ -6272,12 +6262,6 @@ const getNodeModulesCache = async (context, policy = "pull-push") => {
             policy,
             paths: (0, lodash_es_1.uniq)([
                 (0, path_1.join)(baseDir, "node_modules"),
-                // pnpm's per-package node_modules are symlink farms worth
-                // keeping warm (yarn hoists into the root, so root-only
-                // matches its historical behavior)
-                ...(isPnpm
-                    ? workspaces.map((w) => (0, path_1.join)(w.location, "node_modules"))
-                    : []),
                 ...(hasInstallState ? [(0, path_1.join)(baseDir, ".yarn/install-state.gz")] : []),
             ]),
         },
@@ -6469,19 +6453,15 @@ const isInWorkspace = (context, packageManagerInfo) => context.type === "workspa
  */
 const getEnsurePnpmCommand = (version) => `if ! command -v pnpm &> /dev/null; then corepack enable pnpm 2>/dev/null || npm install -g pnpm@${version}; fi`;
 /**
- * pnpm's store is global by default; point it at a project-local
- * directory so CI can cache it (the pnpm equivalent of the `.yarn`
- * zip cache). Passed as the --store-dir flag: pnpm 11 stopped reading
- * the npm_config_store_dir env var (settings only come from
- * pnpm-workspace.yaml / global config / CLI flags), the flag works on
- * v10 and v11
- */
-const getPnpmStoreDirExpression = (inWorkspace) => inWorkspace
-    ? `"$(git rev-parse --show-toplevel 2>/dev/null || pwd)/.pnpm-store"`
-    : `"$PWD/.pnpm-store"`;
-const getPnpmInstallCommands = (context, packageManagerInfo) => [
+ * pnpm jobs use pnpm's own (global, per-runner) store location. There
+ * used to be a `--store-dir` pointing at a project-local
+ * `.pnpm-store`, so CI could cache it — that cache is gone (see
+ * getYarnCache), and keeping the store inside the repo only meant it
+ * landed in docker build contexts.
+ */
+const getPnpmInstallCommands = (packageManagerInfo) => [
     getEnsurePnpmCommand(packageManagerInfo.version),
-    `pnpm install --frozen-lockfile --store-dir ${getPnpmStoreDirExpression(isInWorkspace(context, packageManagerInfo))}`,
+    `pnpm install --frozen-lockfile`,
 ];
 exports.DEFAULT_AUDIT_LEVEL = "critical";
 /**
@@ -6525,7 +6505,7 @@ const getPackageManagerInstall = async (context, options) => {
         ? context.build.config.postInstall
         : null;
     const installSection = packageManagerInfo.type === "pnpm"
-        ? (0, gitlab_1.collapseableSection)("pnpminstall", "pnpm install")(getPnpmInstallCommands(context, packageManagerInfo))
+        ? (0, gitlab_1.collapseableSection)("pnpminstall", "pnpm install")(getPnpmInstallCommands(packageManagerInfo))
         : (0, gitlab_1.collapseableSection)("yarninstall", "Yarn install")([getYarnInstallCommand(packageManagerInfo)]);
     return [
         ...(0, exports.ensureNodeVersion)(context),
@@ -6538,11 +6518,12 @@ const getPackageManagerInstall = async (context, options) => {
 exports.getPackageManagerInstall = getPackageManagerInstall;
 const DOCKER_COPY_FILES = `COPY --chown=node:node $APP_DIR .`;
 const getPnpmDockerAppCopyAndBuildScript = (packageManagerInfo) => {
-    // the store was copied into the image (like the yarn zip cache), so
-    // the prod install links from it instead of hitting the registry
-    const storeDir = packageManagerInfo.componentIsInWorkspace
-        ? "/app/.pnpm-store"
-        : "/app/$APP_DIR/.pnpm-store";
+    // the prod install downloads from the registry: nothing is copied
+    // into the image to link from (see createNodeDockerJobDefinition).
+    // The store it fills is scratch space outside /app, dropped in the
+    // same layer so the packages ship once — node_modules holds
+    // hardlinks, so removing the store keeps the files alive
+    const storeDir = "/tmp/pnpm-store";
     // in a workspace, only install the component (and its workspace
     // dependencies) — the pnpm equivalent of `yarn workspaces focus`.
     // npm package names are shell-safe unquoted (the whole script is
@@ -6554,7 +6535,7 @@ const getPnpmDockerAppCopyAndBuildScript = (packageManagerInfo) => {
     return new bash_1.BashExpression(`
 ${DOCKER_COPY_FILES}
 RUN command -v pnpm >/dev/null 2>&1 || npm install -g pnpm@${packageManagerInfo.version}
-RUN pnpm install --prod --frozen-lockfile --store-dir ${storeDir}${filter}
+RUN pnpm install --prod --frozen-lockfile --store-dir ${storeDir}${filter} && rm -rf ${storeDir}
     `.trim());
 };
 const getDockerAppCopyAndBuildScript = async (context) => {

package/dist/bundles/cli/index.js

@@ -12028,11 +12028,14 @@ const createNodeDockerJobDefinition = async (context) => {
         (0, packageManagerInstall_1.getDockerAppCopyAndBuildScript)(context),
         context.packageManagerInfo,
     ]);
-    // the pnpm store (pulled via the cache above) is copied into the
-    // image so the prod install works offline — like the yarn zip cache,
-    // which travels inside the copied `.yarn` config folder
-    const copyPnpmStore = packageManagerInfo.type === "pnpm" &&
-        packageManagerInfo.componentIsInWorkspace;
+    // The pnpm store is deliberately NOT copied into the image. It used
+    // to be, so the prod install could link instead of hitting the
+    // registry — but the store lands in an earlier layer than
+    // node_modules, so pnpm cannot hardlink across the overlay boundary
+    // and copies every package instead. Measured on one component: the
+    // in-image install was *slower* that way (28s vs 10s from the
+    // registry), the store added 3GB to the build context and the final
+    // image, and the build took 339s instead of 27s.
     // pnpm copies every workspace manifest into the image — as individual
     // COPY instructions that many layers exceed docker's depth limit, so
     // the job tars them up and a single ADD extracts them
@@ -12040,8 +12043,6 @@ const createNodeDockerJobDefinition = async (context) => {
     const WORKSPACE_FILES_TAR = ".catladder-workspace-files.tar";
     return {
         script: [
-            // the COPY source must exist even when the cache was cold
-            ...(copyPnpmStore ? ["mkdir -p .pnpm-store"] : []),
             ...(isPnpm
                 ? [
                     `tar -cf ${WORKSPACE_FILES_TAR} ${packageManagerInfo.pathsToCopyInDocker.join(" ")}`,
@@ -12058,14 +12059,10 @@ const createNodeDockerJobDefinition = async (context) => {
                     `ADD ${WORKSPACE_FILES_TAR} /app/`,
                     // ADD does not apply --chown to extracted tars, and parent
                     // dirs of the entries come out root-owned — fix ownership
-                    // while the stage still runs as root (store not copied yet,
-                    // so this only touches the small manifest tree). Custom
-                    // base images without a node user run as root and don't
-                    // need it, hence the fallback
+                    // while the stage still runs as root (this only touches the
+                    // small manifest tree). Custom base images without a node
+                    // user run as root and don't need it, hence the fallback
                     `RUN chown -R node:node /app || true`,
-                    ...(copyPnpmStore
-                        ? [`COPY --chown=node:node .pnpm-store /app/.pnpm-store`]
-                        : []),
                 ].join("\n")
                 : packageManagerInfo.pathsToCopyInDocker
                     .map((dir) => `COPY --chown=node:node ${dir} /app/${dir}`)
@@ -12099,10 +12096,9 @@ const lodash_es_1 = __nccwpck_require__(50210);
 const path_1 = __nccwpck_require__(16928);
 const slugify_1 = __importDefault(__nccwpck_require__(84007));
 /**
- * stable reference between the two node caches: the package-manager
- * (yarn zip / pnpm store) cache declares itself redundant when the
- * node_modules cache scored an exact-lockfile hit (github skips the
- * ~0.6GB download on warm runs)
+ * stable reference between the two yarn caches: the zip cache declares
+ * itself redundant when the node_modules cache scored an exact-lockfile
+ * hit (github skips the ~0.6GB download on warm runs)
  */
 const NODE_MODULES_CACHE_ID = "node-modules";
 /**
@@ -12130,36 +12126,36 @@ const getCacheBaseDir = async (context) => {
         : ".";
 };
 /**
- * the package manager's download cache: yarn's `.yarn` zip cache, or
- * pnpm's content-addressable store (which catladder points at a
- * project-local `.pnpm-store`, see the install script)
+ * the package manager's download cache: yarn's `.yarn` zip cache.
+ *
+ * pnpm gets nothing. Its store is a content-addressable tree of
+ * hundreds of thousands of small files, and moving it costs more than
+ * the install it saves: measured on a 3800-package monorepo, restoring
+ * the 1 GB store took ~53s on gitlab (which zips file by file) and
+ * ~23s on github, against a from-registry install of ~30-40s. See
+ * getNodeModulesCache for the node_modules half of the same finding.
  */
 const getYarnCache = async (context, policy = "pull-push") => {
     const packageManagerInfo = await context.packageManagerInfo;
-    const isPnpm = packageManagerInfo.type === "pnpm";
+    if (packageManagerInfo.type === "pnpm")
+        return [];
     const baseDir = await getCacheBaseDir(context);
-    // pnpm keeps its store in a format-versioned subdir (v10, v11, ...)
-    // and never cleans old ones up — scope the cache slot by major so a
-    // pnpm upgrade starts a fresh slot instead of dragging the dead old
-    // store tree along in every cache transfer (formats change only on
-    // majors)
-    const pnpmStoreKey = `pnpm-v${packageManagerInfo.version.split(".")[0]}`;
     return [
         {
             scope: "buildDir",
             pathMode: "relative",
             buildDir: baseDir,
-            key: isPnpm ? pnpmStoreKey : "yarn",
+            key: "yarn",
             policy,
-            paths: [isPnpm ? ".pnpm-store" : ".yarn"],
+            paths: [".yarn"],
             // content-key for immutable-cache backends (github); the lockfile
             // decides whether the cached content could have changed
-            keyFiles: [isPnpm ? "pnpm-lock.yaml" : "yarn.lock"],
-            // the package manager's download cache (~hundreds of MB) is only
-            // read when packages have to be (re)installed. When the
-            // node_modules cache hit for the same lockfile, install verifies
-            // its state file and never touches the store — so github skips
-            // downloading this cache entirely
+            keyFiles: ["yarn.lock"],
+            // the yarn zip cache (~hundreds of MB) is only read when packages
+            // have to be (re)installed. When the node_modules cache hit for
+            // the same lockfile, install verifies its state file and never
+            // touches the zips — so github skips downloading this cache
+            // entirely
             redundantOnExactHitOf: NODE_MODULES_CACHE_ID,
         },
     ];
@@ -12168,12 +12164,18 @@ exports.getYarnCache = getYarnCache;
 const getNodeModulesCache = async (context, policy = "pull-push") => {
     const packageManagerInfo = await context.packageManagerInfo;
     const baseDir = await getCacheBaseDir(context);
-    const { workspaces } = packageManagerInfo;
-    const isPnpm = packageManagerInfo.type === "pnpm";
-    const lockFileName = isPnpm ? "pnpm-lock.yaml" : "yarn.lock";
-    // yarn berry tracks install state in .yarn/install-state.gz (pnpm's
-    // equivalent lives inside node_modules and is covered by the paths)
-    const hasInstallState = packageManagerInfo.type === "yarn" && !packageManagerInfo.isClassic;
+    // pnpm gets no node_modules cache either: archiving the tree (root
+    // plus every workspace's symlink farm, >1GB in real monorepos) costs
+    // ~190s per saving job to spare ~6s of install, and a safe pnpm slot
+    // must be keyed by lockfile hash (a pnpm install over a node_modules
+    // from a different lockfile leaves orphaned .pnpm dirs that break
+    // type identity), so it misses on every dependency change anyway.
+    // pnpm projects run entirely uncached — see getYarnCache
+    if (packageManagerInfo.type === "pnpm")
+        return [];
+    const lockFileName = "yarn.lock";
+    // yarn berry tracks install state in .yarn/install-state.gz
+    const hasInstallState = !packageManagerInfo.isClassic;
     // We intentionally do not use the contents of the lockfile as a cache key, as install should always guarantee that the files are updated, but it can still use part of the cache if not all packages are up-to-date.
     // It would slow down all pipelines whenever one adds a new dependency as it will need to download all node_modules again.
     return [
@@ -12181,19 +12183,7 @@ const getNodeModulesCache = async (context, policy = "pull-push") => {
             scope: "global",
             pathMode: "absolute",
             // we use the dirname, not the component name, because in certain cases we have two apps in the same directory and want to share the cache, e.g. when having storybook in the same package.json
-            //
-            // pnpm gets its own, lockfile-keyed cache: node_modules layouts
-            // are not compatible between package managers (a migrating
-            // project must not inherit the yarn slot), and unlike yarn, a
-            // pnpm install on top of a node_modules from a different lockfile
-            // leaves orphaned .pnpm dirs behind that break type identity —
-            // so the slot changes whenever the lockfile changes
-            key: isPnpm
-                ? {
-                    prefix: "pnpm-" + (0, slugify_1.default)(baseDir) + "-node-modules",
-                    files: [(0, path_1.join)(baseDir, "pnpm-lock.yaml")],
-                }
-                : (0, slugify_1.default)(baseDir) + "-node-modules",
+            key: (0, slugify_1.default)(baseDir) + "-node-modules",
             // content-key for immutable-cache backends (github); the lockfile
             // decides whether the cached content could have changed (absolute
             // pathMode: resolve the lockfile explicitly)
@@ -12204,12 +12194,6 @@ const getNodeModulesCache = async (context, policy = "pull-push") => {
             policy,
             paths: (0, lodash_es_1.uniq)([
                 (0, path_1.join)(baseDir, "node_modules"),
-                // pnpm's per-package node_modules are symlink farms worth
-                // keeping warm (yarn hoists into the root, so root-only
-                // matches its historical behavior)
-                ...(isPnpm
-                    ? workspaces.map((w) => (0, path_1.join)(w.location, "node_modules"))
-                    : []),
                 ...(hasInstallState ? [(0, path_1.join)(baseDir, ".yarn/install-state.gz")] : []),
             ]),
         },
@@ -12401,19 +12385,15 @@ const isInWorkspace = (context, packageManagerInfo) => context.type === "workspa
  */
 const getEnsurePnpmCommand = (version) => `if ! command -v pnpm &> /dev/null; then corepack enable pnpm 2>/dev/null || npm install -g pnpm@${version}; fi`;
 /**
- * pnpm's store is global by default; point it at a project-local
- * directory so CI can cache it (the pnpm equivalent of the `.yarn`
- * zip cache). Passed as the --store-dir flag: pnpm 11 stopped reading
- * the npm_config_store_dir env var (settings only come from
- * pnpm-workspace.yaml / global config / CLI flags), the flag works on
- * v10 and v11
- */
-const getPnpmStoreDirExpression = (inWorkspace) => inWorkspace
-    ? `"$(git rev-parse --show-toplevel 2>/dev/null || pwd)/.pnpm-store"`
-    : `"$PWD/.pnpm-store"`;
-const getPnpmInstallCommands = (context, packageManagerInfo) => [
+ * pnpm jobs use pnpm's own (global, per-runner) store location. There
+ * used to be a `--store-dir` pointing at a project-local
+ * `.pnpm-store`, so CI could cache it — that cache is gone (see
+ * getYarnCache), and keeping the store inside the repo only meant it
+ * landed in docker build contexts.
+ */
+const getPnpmInstallCommands = (packageManagerInfo) => [
     getEnsurePnpmCommand(packageManagerInfo.version),
-    `pnpm install --frozen-lockfile --store-dir ${getPnpmStoreDirExpression(isInWorkspace(context, packageManagerInfo))}`,
+    `pnpm install --frozen-lockfile`,
 ];
 exports.DEFAULT_AUDIT_LEVEL = "critical";
 /**
@@ -12457,7 +12437,7 @@ const getPackageManagerInstall = async (context, options) => {
         ? context.build.config.postInstall
         : null;
     const installSection = packageManagerInfo.type === "pnpm"
-        ? (0, gitlab_1.collapseableSection)("pnpminstall", "pnpm install")(getPnpmInstallCommands(context, packageManagerInfo))
+        ? (0, gitlab_1.collapseableSection)("pnpminstall", "pnpm install")(getPnpmInstallCommands(packageManagerInfo))
         : (0, gitlab_1.collapseableSection)("yarninstall", "Yarn install")([getYarnInstallCommand(packageManagerInfo)]);
     return [
         ...(0, exports.ensureNodeVersion)(context),
@@ -12470,11 +12450,12 @@ const getPackageManagerInstall = async (context, options) => {
 exports.getPackageManagerInstall = getPackageManagerInstall;
 const DOCKER_COPY_FILES = `COPY --chown=node:node $APP_DIR .`;
 const getPnpmDockerAppCopyAndBuildScript = (packageManagerInfo) => {
-    // the store was copied into the image (like the yarn zip cache), so
-    // the prod install links from it instead of hitting the registry
-    const storeDir = packageManagerInfo.componentIsInWorkspace
-        ? "/app/.pnpm-store"
-        : "/app/$APP_DIR/.pnpm-store";
+    // the prod install downloads from the registry: nothing is copied
+    // into the image to link from (see createNodeDockerJobDefinition).
+    // The store it fills is scratch space outside /app, dropped in the
+    // same layer so the packages ship once — node_modules holds
+    // hardlinks, so removing the store keeps the files alive
+    const storeDir = "/tmp/pnpm-store";
     // in a workspace, only install the component (and its workspace
     // dependencies) — the pnpm equivalent of `yarn workspaces focus`.
     // npm package names are shell-safe unquoted (the whole script is
@@ -12486,7 +12467,7 @@ const getPnpmDockerAppCopyAndBuildScript = (packageManagerInfo) => {
     return new bash_1.BashExpression(`
 ${DOCKER_COPY_FILES}
 RUN command -v pnpm >/dev/null 2>&1 || npm install -g pnpm@${packageManagerInfo.version}
-RUN pnpm install --prod --frozen-lockfile --store-dir ${storeDir}${filter}
+RUN pnpm install --prod --frozen-lockfile --store-dir ${storeDir}${filter} && rm -rf ${storeDir}
     `.trim());
 };
 const getDockerAppCopyAndBuildScript = async (context) => {

package/dist/bundles/skills/catladder-migrate-package-manager/SKILL.md

@@ -40,9 +40,9 @@ change needed:
 
 | | yarn | pnpm |
 |---|---|---|
-| CI install | `yarn install --immutable` | `pnpm install --frozen-lockfile --store-dir …` |
-| download cache | `.yarn` zip cache | project-local `.pnpm-store`, cache slot scoped by pnpm major |
-| node_modules cache | mutable slot per build dir | **lockfile-keyed** slot (a pnpm install over a foreign tree leaves orphaned `.pnpm` dirs) |
+| CI install | `yarn install --immutable` | `pnpm install --frozen-lockfile` |
+| download cache | `.yarn` zip cache | **none** — installing from the registry is cheaper than moving the store |
+| node_modules cache | mutable slot per build dir | **none** (measured: the archive costs more than the install it saves) |
 | docker prod install | `yarn workspaces focus --production` | `pnpm install --prod --frozen-lockfile --filter <pkg>...` |
 | audit job | `yarn npm audit … --all --recursive` | `pnpm audit --prod --audit-level critical` |
 | build/start defaults | `yarn build` / `yarn start` | `pnpm build` / `pnpm start` |
@@ -146,9 +146,9 @@ skip it and run a bare `pnpm install` — that silently upgrades hundreds
 of transitive dependencies at the same time as the package manager
 changes, and you will not know which change broke what.
 
-Then set the `packageManager` field, and update `.gitignore`:
-`.pnpm-store/` in, `.yarn/*` entries out (keep `.yarn/patches` only if
-you left the patches there).
+Then set the `packageManager` field, and update `.gitignore`: `.yarn/*`
+entries out (keep `.yarn/patches` only if you left the patches there).
+Nothing pnpm-specific needs ignoring — the store lives outside the repo.
 
 ## Step 4 — fix the fallout locally
 
@@ -231,8 +231,8 @@ Mirrored, with one loss to state up front: **there is no importer back**.
 every range — the migration necessarily bumps transitive versions.
 Do it deliberately:
 
-1. Delete `pnpm-lock.yaml`, `pnpm-workspace.yaml`, `.pnpm-store`, and the
-   `node_modules` trees.
+1. Delete `pnpm-lock.yaml`, `pnpm-workspace.yaml`, and the `node_modules`
+   trees.
 2. Move `packages:` back into package.json `workspaces`, `overrides` →
    `resolutions`, `patchedDependencies` → yarn's patch protocol,
    `allowBuilds` → (yarn runs build scripts by default; nothing needed).

package/dist/bundles/skills/catladder-migrate-package-manager/references/yarn-to-pnpm-differences.md

@@ -82,9 +82,26 @@ the docker build context.
 
 **Version drift in `--prod` installs.** `pnpm install --prod` on a
 node_modules tree from a *different* lockfile does not prune orphaned
-`.pnpm` directories. That is why catladder keys the pnpm node_modules
-cache by the lockfile instead of reusing a mutable slot — and why you
-should never reuse a yarn branch's cache for a pnpm branch.
+`.pnpm` directories — never reuse one branch's node_modules for another
+lockfile, and never a yarn tree for a pnpm branch.
+
+**Nothing is cached.** A yarn pipeline caches its zip cache and
+node_modules; a pnpm pipeline caches neither, and does not copy a store
+into docker images either. pnpm installs a 3800-package monorepo from
+the registry in 30-40s, which is less than it costs to move a 1 GB
+store or a 1.3 GB node_modules tree through a CI cache — measured
+side-by-side, caching made jobs about twice as slow on gitlab. Two
+consequences when migrating: CI pulls more from the registry than the
+yarn setup did (worth a registry proxy if that matters to you), and
+`.pnpm-store` should not appear anywhere in the repo or a build
+context.
+
+**Docker images must not carry the store.** If a store is copied into
+an image, it lands in a layer below `node_modules`, pnpm cannot hardlink
+across the overlay boundary, and every package is copied instead — the
+install gets *slower* (28s vs 10s from the registry) and the image
+carries the packages twice. Let the `--prod` install download, into a
+store outside the app directory that the same `RUN` layer deletes.
 
 **pnpm 11 needs node ≥ 22.13** (pnpm 10: ≥ 18.12), and it does not fail
 politely: it prints a `warn:` line and then crashes on

package/dist/bundles/skills/catladder-pipelines/SKILL.md

@@ -58,12 +58,13 @@ the registry.
 
 ## Caching
 
-Cache configuration is generated per build type; node builds cache
-`node_modules` and the package manager's download cache (the `.yarn`
-zip cache, or for pnpm projects a project-local `.pnpm-store`). GitLab
-uses mutable caches with
-fallback keys (review branches fall back to the dev cache); GitHub uses
-immutable lockfile-keyed caches where only the build job writes.
+Cache configuration is generated per build type. **yarn** node builds
+cache `node_modules` and the `.yarn` zip cache; GitLab uses mutable
+caches with fallback keys (review branches fall back to the dev cache),
+GitHub immutable lockfile-keyed caches where only the build job writes.
+**pnpm** builds cache nothing: measured on a 3800-package monorepo,
+moving the store or node_modules through a CI cache costs more than
+pnpm's from-registry install.
 Caching behavior is changed via the build config in `catladder.ts`,
 not in the YAML.
 

package/dist/packages/pipeline/src/build/node/buildJob.js

@@ -44,11 +44,14 @@ const createNodeDockerJobDefinition = async (context) => {
         (0, packageManagerInstall_1.getDockerAppCopyAndBuildScript)(context),
         context.packageManagerInfo,
     ]);
-    // the pnpm store (pulled via the cache above) is copied into the
-    // image so the prod install works offline — like the yarn zip cache,
-    // which travels inside the copied `.yarn` config folder
-    const copyPnpmStore = packageManagerInfo.type === "pnpm" &&
-        packageManagerInfo.componentIsInWorkspace;
+    // The pnpm store is deliberately NOT copied into the image. It used
+    // to be, so the prod install could link instead of hitting the
+    // registry — but the store lands in an earlier layer than
+    // node_modules, so pnpm cannot hardlink across the overlay boundary
+    // and copies every package instead. Measured on one component: the
+    // in-image install was *slower* that way (28s vs 10s from the
+    // registry), the store added 3GB to the build context and the final
+    // image, and the build took 339s instead of 27s.
     // pnpm copies every workspace manifest into the image — as individual
     // COPY instructions that many layers exceed docker's depth limit, so
     // the job tars them up and a single ADD extracts them
@@ -56,8 +59,6 @@ const createNodeDockerJobDefinition = async (context) => {
     const WORKSPACE_FILES_TAR = ".catladder-workspace-files.tar";
     return {
         script: [
-            // the COPY source must exist even when the cache was cold
-            ...(copyPnpmStore ? ["mkdir -p .pnpm-store"] : []),
             ...(isPnpm
                 ? [
                     `tar -cf ${WORKSPACE_FILES_TAR} ${packageManagerInfo.pathsToCopyInDocker.join(" ")}`,
@@ -74,14 +75,10 @@ const createNodeDockerJobDefinition = async (context) => {
                     `ADD ${WORKSPACE_FILES_TAR} /app/`,
                     // ADD does not apply --chown to extracted tars, and parent
                     // dirs of the entries come out root-owned — fix ownership
-                    // while the stage still runs as root (store not copied yet,
-                    // so this only touches the small manifest tree). Custom
-                    // base images without a node user run as root and don't
-                    // need it, hence the fallback
+                    // while the stage still runs as root (this only touches the
+                    // small manifest tree). Custom base images without a node
+                    // user run as root and don't need it, hence the fallback
                     `RUN chown -R node:node /app || true`,
-                    ...(copyPnpmStore
-                        ? [`COPY --chown=node:node .pnpm-store /app/.pnpm-store`]
-                        : []),
                 ].join("\n")
                 : packageManagerInfo.pathsToCopyInDocker
                     .map((dir) => `COPY --chown=node:node ${dir} /app/${dir}`)