The clone command computed its content directory path by substring-
splitting __dirname on '/src/' or '/lib/'. In a published/installed
layout this breaks because the install path itself can contain
'/lib/' (e.g. Node's own lib/node_modules), so the split matched the
wrong occurrence and resolved to an ancestor directory instead of the
package root.
As a result, the pre-clone check, the post-import cleanup, and the
interrupt-handler cleanup were all deleting an unrelated, effectively
empty directory, while the actual export/import data (written to the
correct path via clone-handler.ts's own resolution) was never cleaned
up. Content from a previous clone run persisted on disk and bled into
subsequent clones of a different stack.
Resolve packageRoot by fixed relative directory depth instead,
matching the approach already used in clone-handler.ts. This is
independent of the surrounding install path and has been verified
against nested, flat/hoisted, and pnpm virtual-store install layouts.
Summary
The
cm:stacks:clonecommand computed its content directory path by substring-splitting__dirnameon/src/or/lib/:In a real installed environment this is unreliable, because the install path itself can contain
/lib/more than once (for example, Node's ownlib/node_modulesdirectory, in addition to this package's own compiledlib/output)..split('/lib/')[0]matches the first occurrence, so it resolved to an unrelated ancestor directory instead of the package's actual root.Every cleanup path in the command — the pre-clone check that clears leftover data, the post-import cleanup on success, and the interrupt-handler cleanup — used this incorrectly-resolved path. All three were faithfully deleting a directory that was essentially always empty, while the real export/import data (resolved correctly and independently in
clone-handler.tsviapath.resolve) was never targeted by any cleanup call.Net effect: content from a completed clone run stayed on disk indefinitely and bled into the next clone of a different stack, causing content-type/entry resolution failures during export.
Fix
Resolve
packageRootby fixed relative directory depth instead of string matching, mirroring the approachclone-handler.tsalready uses:commands/cm/stacksis always exactly 3 directories below the package'ssrc/libroot, so this reliably lands on the package root regardless of how the surrounding path is structured — it doesn't depend on any substring content of the install path at all.Verification
Content directory pathline (cleanup target) and theExport directoryline (actual data path) diverged before the fix, and a subsequent clone into a different stack printed"The export directory is not empty. Existing files in this folder may be overwritten."packageRootresolution against nested (.../node_modules/@scope/cli/node_modules/@scope/pkg/...), flat/hoisted, and pnpm.pnpmvirtual-store install layouts — all resolve correctly.rimrafcalls exist in the package, both scoped to a single fixedcontentssubfolder underpackageRoot, andpathDircannot be overridden by a user-supplied external config (it's set after the config merge, unconditionally).tsc --noEmitandtsc -bboth pass cleanly.Test plan
contents/directory is removed afterward