stonyx 0.2.3-alpha.7 → 0.2.3-alpha.71

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 (69) hide show
  1. package/README.md +30 -7
  2. package/config/{environment.js → environment copy.ts } +16 -12
  3. package/dist/cli/help.d.ts +8 -0
  4. package/dist/cli/help.js +43 -0
  5. package/dist/cli/load-commands.d.ts +10 -0
  6. package/dist/cli/load-commands.js +49 -0
  7. package/dist/cli/new.d.ts +72 -0
  8. package/dist/cli/new.js +422 -0
  9. package/dist/cli/serve.d.ts +6 -0
  10. package/dist/cli/serve.js +49 -0
  11. package/dist/cli/test-setup.d.ts +1 -0
  12. package/dist/cli/test-setup.js +30 -0
  13. package/dist/cli/test.d.ts +4 -0
  14. package/dist/cli/test.js +23 -0
  15. package/dist/cli.d.ts +2 -0
  16. package/dist/cli.js +53 -0
  17. package/dist/exports/config.d.ts +2 -0
  18. package/dist/exports/config.js +2 -0
  19. package/dist/exports/log.d.ts +2 -0
  20. package/{src → dist}/exports/log.js +1 -2
  21. package/dist/exports/test-helpers.d.ts +5 -0
  22. package/dist/exports/test-helpers.js +7 -0
  23. package/dist/lifecycle.d.ts +7 -0
  24. package/dist/lifecycle.js +18 -0
  25. package/dist/main.d.ts +22 -0
  26. package/dist/main.js +102 -0
  27. package/dist/modules.d.ts +5 -0
  28. package/dist/modules.js +186 -0
  29. package/dist/util/duplicate-core.d.ts +186 -0
  30. package/dist/util/duplicate-core.js +377 -0
  31. package/dist/util/import-config.d.ts +52 -0
  32. package/dist/util/import-config.js +256 -0
  33. package/dist/util/resolve-entry-point.d.ts +1 -0
  34. package/dist/util/resolve-entry-point.js +14 -0
  35. package/dist/util/resolve-module-name.d.ts +14 -0
  36. package/dist/util/resolve-module-name.js +33 -0
  37. package/package.json +41 -12
  38. package/scripts/postinstall.js +24 -2
  39. package/.claude/index.md +0 -96
  40. package/.github/workflows/ci.yml +0 -16
  41. package/.github/workflows/publish.yml +0 -51
  42. package/docs/api.md +0 -89
  43. package/docs/cli.md +0 -78
  44. package/docs/configuration.md +0 -72
  45. package/docs/conventions/discord-conventions.md +0 -62
  46. package/docs/conventions/framework-modules.md +0 -127
  47. package/docs/conventions/index.md +0 -24
  48. package/docs/conventions/orm-conventions.md +0 -190
  49. package/docs/conventions/project-structure.md +0 -105
  50. package/docs/conventions/rest-conventions.md +0 -96
  51. package/docs/conventions/testing-conventions.md +0 -56
  52. package/docs/developing-modules.md +0 -108
  53. package/docs/index.md +0 -15
  54. package/docs/lifecycle.md +0 -47
  55. package/docs/logging.md +0 -52
  56. package/docs/modules.md +0 -78
  57. package/docs/testing.md +0 -64
  58. package/src/cli/help.js +0 -48
  59. package/src/cli/load-commands.js +0 -56
  60. package/src/cli/new.js +0 -237
  61. package/src/cli/serve.js +0 -38
  62. package/src/cli/test-setup.js +0 -8
  63. package/src/cli/test.js +0 -27
  64. package/src/cli.js +0 -63
  65. package/src/exports/config.js +0 -3
  66. package/src/exports/test-helpers.js +0 -8
  67. package/src/lifecycle.js +0 -17
  68. package/src/main.js +0 -101
  69. package/src/modules.js +0 -112
package/dist/main.d.ts ADDED
@@ -0,0 +1,22 @@
1
+ import Chronicle from '@stonyx/logs';
2
+ import type { StoynxModule } from './lifecycle.js';
3
+ import type { StoynxConfig } from './modules.js';
4
+ export default class Stonyx {
5
+ static initialized: boolean;
6
+ static modulePromises: Record<string, unknown>;
7
+ static instance: Stonyx;
8
+ static ready: Promise<void>;
9
+ config: StoynxConfig;
10
+ chronicle: Chronicle;
11
+ modules: StoynxModule[];
12
+ constructor(config: StoynxConfig, rootPath: string);
13
+ start(config: StoynxConfig, rootPath: string): Promise<void>;
14
+ /**
15
+ * Allows users to define their own log for any extra class via environment config
16
+ */
17
+ configureUserLogs(): void;
18
+ static get log(): Chronicle;
19
+ static get config(): StoynxConfig;
20
+ }
21
+ export { waitForModule } from './modules.js';
22
+ export type { StoynxConfig } from './modules.js';
package/dist/main.js ADDED
@@ -0,0 +1,102 @@
1
+ /*
2
+ * Copyright 2025 Stone Costa
3
+ *
4
+ * Licensed under the Apache License, Version 2.0 (the "License");
5
+ * you may not use this file except in compliance with the License.
6
+ * You may obtain a copy of the License at
7
+ *
8
+ * http://www.apache.org/licenses/LICENSE-2.0
9
+ *
10
+ * Unless required by applicable law or agreed to in writing, software
11
+ * distributed under the License is distributed on an "AS IS" BASIS,
12
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13
+ * See the License for the specific language governing permissions and
14
+ * limitations under the License.
15
+ */
16
+ import Chronicle from '@stonyx/logs';
17
+ import loadModules from './modules.js';
18
+ import { mergeObject } from '@stonyx/utils/object';
19
+ import { importConfig, CONFIG_NOT_FOUND_PREFIX } from './util/import-config.js';
20
+ import { resolveModuleName } from './util/resolve-module-name.js';
21
+ export default class Stonyx {
22
+ static initialized = false;
23
+ static modulePromises = {};
24
+ static instance;
25
+ static ready;
26
+ config;
27
+ chronicle;
28
+ modules;
29
+ constructor(config, rootPath) {
30
+ if (Stonyx.instance)
31
+ return Stonyx.instance;
32
+ Stonyx.instance = this;
33
+ Stonyx.ready = this.start(config, rootPath);
34
+ }
35
+ async start(config, rootPath) {
36
+ if (!config)
37
+ throw new Error('Stonyx requires full environment configuration on startup');
38
+ if (!rootPath)
39
+ throw new Error('Stonyx requires root project\'s path on startup');
40
+ // Transform config from stonyx-modules running as a standalone.
41
+ // Signal is the consumer's `package.json#name` (see resolveModuleName);
42
+ // this replaces the brittle `rootPath.includes('stonyx-')` heuristic so
43
+ // non-canonical rootPaths (worktrees, forks, renames) still work.
44
+ const moduleName = resolveModuleName(rootPath);
45
+ if (moduleName) {
46
+ const flatConfig = config;
47
+ const siblingModules = flatConfig.modules || {};
48
+ config = { [moduleName]: config, ...siblingModules };
49
+ delete config.modules;
50
+ }
51
+ this.config = config;
52
+ this.chronicle = new Chronicle({ additionalLogs: { title: 'green' } });
53
+ Stonyx.initialized = true;
54
+ // Auto-merge test environment overrides (after initialized flag, before modules load)
55
+ // Uses in-place mutation to preserve existing references (e.g. stonyx/config export cache)
56
+ if (process.env.NODE_ENV === 'test') {
57
+ try {
58
+ const testOverrides = await importConfig(`${rootPath}/test/config/environment`);
59
+ const merged = mergeObject(config, testOverrides);
60
+ Object.assign(config, merged);
61
+ }
62
+ catch (err) {
63
+ // A test override that is genuinely ABSENT is non-fatal. Everything else
64
+ // re-throws — including `CONFIG_NOT_LOADABLE_PREFIX`, which is the whole
65
+ // point of that prefix existing (abofs/stonyx#105, invariant I2). A
66
+ // config the consumer wrote and this loader declined must never reach
67
+ // the caller as "you have no test overrides".
68
+ if (!(err instanceof Error) || !err.message.startsWith(CONFIG_NOT_FOUND_PREFIX))
69
+ throw err;
70
+ }
71
+ }
72
+ this.modules = await loadModules(config, rootPath, this.chronicle);
73
+ this.configureUserLogs();
74
+ }
75
+ /**
76
+ * Allows users to define their own log for any extra class via environment config
77
+ */
78
+ configureUserLogs() {
79
+ const { chronicle } = this;
80
+ for (const [className, config] of Object.entries(this.config)) {
81
+ if (!config || typeof config !== 'object')
82
+ continue;
83
+ if (className in chronicle)
84
+ continue;
85
+ const { logColor, logMethod, logTimestamp } = config;
86
+ if (!logColor)
87
+ continue;
88
+ chronicle.defineType(logMethod || className, logColor, { logTimestamp: !!logTimestamp });
89
+ }
90
+ }
91
+ static get log() {
92
+ if (!Stonyx.initialized)
93
+ throw new Error('Stonyx has not been initialized yet');
94
+ return Stonyx.instance.chronicle;
95
+ }
96
+ static get config() {
97
+ if (!Stonyx.initialized)
98
+ throw new Error('Stonyx has not been initialized yet');
99
+ return Stonyx.instance.config;
100
+ }
101
+ }
102
+ export { waitForModule } from './modules.js';
@@ -0,0 +1,5 @@
1
+ import type { StoynxModule } from './lifecycle.js';
2
+ import type Chronicle from '@stonyx/logs';
3
+ export type StoynxConfig = Record<string, Record<string, unknown> | unknown>;
4
+ export default function loadModules(config: StoynxConfig, rootPath: string, chronicle: Chronicle): Promise<StoynxModule[]>;
5
+ export declare function waitForModule(moduleName: string): Promise<void>;
@@ -0,0 +1,186 @@
1
+ /**
2
+ * Validates and initializes stonyx modules
3
+ * TODO: Refactor into a ModuleLoader class (good coding exercise)
4
+ */
5
+ import { readFile } from '@stonyx/utils/file';
6
+ import { kebabCaseToCamelCase } from '@stonyx/utils/string';
7
+ import { mergeObject } from '@stonyx/utils/object';
8
+ import { importConfig, CONFIG_NOT_FOUND_PREFIX, CONFIG_NOT_LOADABLE_PREFIX } from './util/import-config.js';
9
+ import { findForeignCores, duplicateCoreMessage } from './util/duplicate-core.js';
10
+ const modulePromises = {};
11
+ // Configure module-specific logging
12
+ function configureLog(chronicle, module, config) {
13
+ const { logColor, logMethod, logTimestamp } = config;
14
+ if (!logColor)
15
+ return;
16
+ chronicle.defineType(logMethod || module, logColor, { logTimestamp: !!logTimestamp });
17
+ }
18
+ function initializeModule(moduleName, moduleClass, modules, initPromises) {
19
+ const moduleInstance = new moduleClass();
20
+ modules.push(moduleInstance);
21
+ if (!moduleInstance.init)
22
+ return;
23
+ initPromises.push((async () => {
24
+ await moduleInstance.init();
25
+ modulePromises[moduleName]?.resolve();
26
+ })());
27
+ }
28
+ function messageOf(error) {
29
+ return error instanceof Error ? error.message : String(error);
30
+ }
31
+ /**
32
+ * Why the old single catch had to go (abofs/stonyx#108, invariant I2).
33
+ *
34
+ * It spanned four distinct failure modes — config absent, config present and
35
+ * declined, config throwing, entry point failing — and collapsed all four into
36
+ * one fixed claim: `Stonyx modules with async loading must have a
37
+ * config/environment.js file`. In the reproduction #108 was filed over, BOTH
38
+ * facts in that sentence were false: the named file existed and imported
39
+ * cleanly with nine keys, and the module named was not the module that threw.
40
+ * The real error reached stderr only through a bare `console.error`, unlinked
41
+ * from the thrown one, so a programmatic supervisor — or any log aggregator
42
+ * that keeps the thrown message — lost the diagnosis entirely.
43
+ *
44
+ * `CONFIG_NOT_LOADABLE_PREFIX` was exported by abofs/stonyx#105 for exactly
45
+ * this branch and had zero non-test importers in `src/` until now; #116
46
+ * corrected the doc sentence and deliberately left the code here.
47
+ *
48
+ * NOT DONE, deliberately: #108's AC1 asks that a surviving config-file message
49
+ * be "guarded by an `existsSync` on the module's own config/environment.js".
50
+ * That guard could not fail. `importConfig` throws `CONFIG_NOT_FOUND_PREFIX`
51
+ * only after `existsSync` has already returned false for every extension it
52
+ * loads AND every extension it merely detects, so an `existsSync` re-check in
53
+ * this branch is true by construction — a check that cannot red, which is the
54
+ * defect family this cluster exists to remove. The branch is keyed on the
55
+ * loader's own outcome instead, and the literal string is gone from `src/`
56
+ * altogether, which is what the grep in that AC actually measures.
57
+ *
58
+ * SCOPE: this names which STEP failed and preserves the original verbatim. It
59
+ * does not diagnose WHY a module's own config threw, and it cannot tell a
60
+ * module that ships no config from one whose install was truncated.
61
+ */
62
+ function describeConfigFailure(moduleName, configBasePath, error) {
63
+ const message = messageOf(error);
64
+ if (message.startsWith(CONFIG_NOT_FOUND_PREFIX)) {
65
+ return new Error(`Stonyx module "${moduleName}" carries the "stonyx-async" keyword, which requires it to ship ` +
66
+ `default configuration, and none is installed. Looked for ${configBasePath}.ts and ` +
67
+ `${configBasePath}.js. This file ships inside "${moduleName}" — a missing one is a truncated ` +
68
+ 'or corrupted install of that module, not a mistake in this app\'s own config.', { cause: error });
69
+ }
70
+ if (message.startsWith(CONFIG_NOT_LOADABLE_PREFIX)) {
71
+ return new Error(`Stonyx module "${moduleName}" ships default configuration this Node runtime declined to ` +
72
+ `load. ${message}`, { cause: error });
73
+ }
74
+ return new Error(`Stonyx module "${moduleName}" failed while loading its default configuration from ` +
75
+ `${configBasePath}: ${message}`, { cause: error });
76
+ }
77
+ export default async function loadModules(config, rootPath, chronicle) {
78
+ const modules = [];
79
+ const initPromises = [];
80
+ const rootPackage = await readFile(`${rootPath}/package.json`, { json: true });
81
+ const dependencies = (rootPackage.devDependencies || {});
82
+ const projectName = typeof rootPackage.name === 'string' ? rootPackage.name : '';
83
+ // Expose rootPath to public configuration
84
+ config.rootPath = rootPath;
85
+ const moduleDependencies = Object.keys(dependencies).filter((moduleName) => moduleName.startsWith('@stonyx/'));
86
+ // Setup module promises prior to initialization
87
+ for (const moduleName of moduleDependencies) {
88
+ const promise = {};
89
+ modulePromises[moduleName] = promise;
90
+ promise.ready = new Promise(resolve => promise.resolve = resolve);
91
+ }
92
+ // DISCOVERY, hoisted above the pre-flight.
93
+ //
94
+ // The pre-flight must check exactly what the loader loads, and no more.
95
+ // `@stonyx/*` is a NAME test, not a membership test: a scoped devDependency
96
+ // without the `stonyx-module` keyword is warned about and skipped below —
97
+ // never imported, never configured, incapable of registering anything on any
98
+ // singleton — and refusing to boot over its nested copy prescribed the MODULE
99
+ // AUTHOR's remedy to a package that is not a module and has no such
100
+ // obligation. #106 says the two predicates are different in as many words.
101
+ // So the keyword gate runs first and the pre-flight sees only real modules.
102
+ const discovered = [];
103
+ for (const moduleName of moduleDependencies) {
104
+ const modulePackage = await readFile(`${rootPath}/node_modules/${moduleName}/package.json`, { json: true, missingFileCallback: (_filePath) => {
105
+ console.warn(`Warning: Could not locate stonyx module: "${moduleName}". Module was not loaded`);
106
+ return '';
107
+ } });
108
+ if (!modulePackage)
109
+ continue;
110
+ const keywords = Array.isArray(modulePackage.keywords) ? modulePackage.keywords : [];
111
+ if (!keywords.includes('stonyx-module')) {
112
+ console.warn(`Warning: Stonyx modules must contain the "stonyx-module" keyword. Module was not loaded`);
113
+ continue;
114
+ }
115
+ discovered.push({
116
+ name: moduleName,
117
+ dir: `${rootPath}/node_modules/${moduleName}`,
118
+ package: modulePackage,
119
+ keywords,
120
+ });
121
+ }
122
+ // Pre-flight: invariant I1, "one core". Before ANY module entry point is
123
+ // imported, because the point of the check is the module that would NOT
124
+ // throw — it would load, initialise, and register its hooks on a second
125
+ // singleton that nobody started. See src/util/duplicate-core.ts.
126
+ //
127
+ // It runs over every discovered module, SYNC AND ASYNC ALIKE. A sync module
128
+ // is never imported by the loader, so its second core never announces itself
129
+ // — which is exactly why the mechanism is a pre-flight and not a better
130
+ // catch. The consequence is that `stonyx-async` no longer decides whether a
131
+ // duplicate core is loud: both arms are refused here, by the same check,
132
+ // before the keyword is ever read. docs/modules.md documents that.
133
+ //
134
+ // `console.warn` for the inconclusive probes: fail-open is the policy, but
135
+ // "we could not check" must be distinguishable from "we checked and it is
136
+ // fine". This is the file's existing idiom for a non-fatal loader advisory.
137
+ const foreignCores = findForeignCores(discovered.map(({ name, dir }) => ({ name, dir })), undefined, message => console.warn(message));
138
+ if (foreignCores.length > 0)
139
+ throw new Error(duplicateCoreMessage(foreignCores));
140
+ // Standalone module configuration
141
+ if (Array.isArray(rootPackage.keywords) && rootPackage.keywords.includes('stonyx-module')) {
142
+ configureLog(chronicle, projectName, config);
143
+ const entryPoint = typeof rootPackage.main === 'string' ? rootPackage.main : '';
144
+ const { default: moduleClass } = await import(`${rootPath}/${entryPoint}`);
145
+ initializeModule(projectName, moduleClass, modules, initPromises);
146
+ }
147
+ for (const { name: moduleName, package: modulePackage, keywords } of discovered) {
148
+ if (!keywords.includes('stonyx-async')) {
149
+ modulePromises[moduleName].resolve();
150
+ continue;
151
+ }
152
+ // Load & Configure Async Modules
153
+ const configBasePath = `${rootPath}/node_modules/${moduleName}/config/environment`;
154
+ let moduleConfig;
155
+ try {
156
+ moduleConfig = await importConfig(configBasePath);
157
+ }
158
+ catch (error) {
159
+ throw describeConfigFailure(moduleName, configBasePath, error);
160
+ }
161
+ const module = kebabCaseToCamelCase(moduleName.split('/').pop() ?? moduleName);
162
+ const userConfig = config[module] || {};
163
+ const finalConfig = mergeObject(moduleConfig, userConfig);
164
+ config[module] = finalConfig;
165
+ // Configure module-specific logging
166
+ configureLog(chronicle, module, finalConfig);
167
+ const entryPath = `${rootPath}/node_modules/${moduleName}/${modulePackage.main}`;
168
+ try {
169
+ const { default: moduleClass } = await import(entryPath);
170
+ initializeModule(moduleName, moduleClass, modules, initPromises);
171
+ }
172
+ catch (error) {
173
+ throw new Error(`Stonyx module "${moduleName}" failed while importing its entry point ${entryPath}: ${messageOf(error)}`, { cause: error });
174
+ }
175
+ }
176
+ // Wait until all modules are initialized
177
+ await Promise.all(initPromises);
178
+ return modules;
179
+ }
180
+ export async function waitForModule(moduleName) {
181
+ const fullName = `@stonyx/${moduleName}`;
182
+ const modulePromise = modulePromises[fullName];
183
+ if (!modulePromise)
184
+ throw new Error(`Could wait for module: ${fullName}. Module was not registered in project dependencies`);
185
+ await modulePromises[fullName].ready;
186
+ }
@@ -0,0 +1,186 @@
1
+ /** A resolved `stonyx` package: where it physically is, and what version. */
2
+ export interface CorePackage {
3
+ /** Absolute, symlink-resolved package root (the directory holding package.json). */
4
+ root: string;
5
+ version: string;
6
+ }
7
+ export interface ForeignCore {
8
+ moduleName: string;
9
+ moduleCore: CorePackage;
10
+ runningCore: CorePackage;
11
+ }
12
+ /**
13
+ * Told when the probe could not reach a conclusion.
14
+ *
15
+ * FAIL-OPEN IS THE POLICY; SILENCE IS NOT. `findForeignCores` must never invent
16
+ * a boot failure out of an inconclusive probe — but "we could not check" has to
17
+ * be distinguishable from "we checked and it is fine", because the states that
18
+ * fail open are exactly the states in which a genuine second core is present
19
+ * and unreported. Measured on trees that DO carry a second core, each of these
20
+ * boots clean and silent while the control throws in the same run:
21
+ *
22
+ * - an interposed `dist/package.json`, so the running core cannot name itself
23
+ * - a nested `stonyx/package.json` that is not valid JSON
24
+ * - the same file at `chmod 000`
25
+ *
26
+ * A reporter can only write a line. It cannot change the outcome.
27
+ */
28
+ export type InconclusiveReporter = (message: string) => void;
29
+ /**
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`.
32
+ *
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
41
+ * folders — `NODE_PATH`, `~/.node_modules`, `~/.node_libraries`, the node
42
+ * prefix. ESM ignores every one of those, so honouring them invents a
43
+ * "duplicate" out of an ambient environment variable that the real import never
44
+ * consults. This workspace exports `NODE_PATH` at a different `stonyx`
45
+ * (abofs/stonyx#107), so that false positive is not hypothetical: it flips a
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. WHICH CJS ENUMERATION IS MEANT
51
+ * IS PART OF THE CLAIM, because the two are not the same set: the walk PROPER
52
+ * is `Module._nodeModulePaths`, and `require.resolve.paths` is that walk
53
+ * FOLLOWED BY the global folders of the paragraph above. It is the walk proper
54
+ * that never descends into a directory already named `node_modules`. **ESM's
55
+ * PACKAGE_RESOLVE has no such skip.** Measured with no `NODE_PATH` at all,
56
+ * from a module at `<app>/node_modules/@stonyx/x`:
57
+ *
58
+ * import.meta.resolve('stonyx') -> <app>/node_modules/node_modules/stonyx/main.js
59
+ * await import('stonyx') -> that copy
60
+ * require.resolve('stonyx') -> MODULE_NOT_FOUND
61
+ *
62
+ * A genuine second core there was missed silently. Worse, because ESM reaches
63
+ * the ancestor `<app>/node_modules` BEFORE `<app>`, that copy SHADOWS a correct
64
+ * local core at `<app>/node_modules/stonyx` while the pre-flight reported
65
+ * success — this file's own opening paragraph ("it loads, it initialises, it
66
+ * reports success, and its hooks silently never fire") surviving the check
67
+ * written to catch it. Isolating control, moving nothing but the directory: the
68
+ * same core at `<app>/node_modules/@stonyx/x/node_modules/stonyx` was REFUSED.
69
+ *
70
+ * THE SET DELTA, both directions and named per enumeration — node v24.13.0,
71
+ * from that same module dir. Against the WALK PROPER the difference is one
72
+ * directory and it is one-sided: `esm \ Module._nodeModulePaths` = exactly
73
+ * `<app>/node_modules/node_modules` (the miss above), and
74
+ * `Module._nodeModulePaths \ esm` = `[]`. Against `require.resolve.paths` the
75
+ * second direction is NOT empty and never was: `require.resolve.paths \ esm` =
76
+ * the three global folders (measured here: `~/.node_modules`,
77
+ * `~/.node_libraries` and the node prefix, all three absent on disk) PLUS one
78
+ * entry per `NODE_PATH` component, four more as this workspace exports it. That tail IS the "too wide" defect above, measured rather than
79
+ * argued, and it is why an unqualified "the CJS candidates are the same" is
80
+ * true of one enumeration and false of the other.
81
+ *
82
+ * BOUNDED BY ANCESTRY, not by a rule. `<app>/node_modules/node_modules` is a
83
+ * candidate because `<app>/node_modules` is an ancestor of the module dir; two
84
+ * levels of nesting is not a candidate, because
85
+ * `<app>/node_modules/node_modules` is not an ancestor of it. Measured: a core
86
+ * planted two levels deep resolves to the real core, and is correctly ignored.
87
+ *
88
+ * THE REJECTED ALTERNATIVE, and the correction that goes with it. While the
89
+ * candidates still came from `require.resolve.paths`, `Module.globalPaths` was
90
+ * reviewed as the screen instead of a shape test, and rejected here on typing
91
+ * grounds plus the claim that the two "admit the identical set". MEASURED, that
92
+ * claim is FALSE, and false in the direction that matters: `globalPaths` filters
93
+ * by STRING MEMBERSHIP, so whenever `NODE_PATH` names a directory that is also
94
+ * a genuine walk entry, the provenance screen drops the walk entry too. Pointed
95
+ * at `<app>/node_modules` with a real second core inside it:
96
+ *
97
+ * NODE_PATH=<app>/node_modules provenance -> no core found
98
+ * shape -> 0.0.0-APP-LOCAL-SECOND-CORE
99
+ * NODE_PATH unset (control) provenance -> 0.0.0-APP-LOCAL-SECOND-CORE
100
+ * shape -> 0.0.0-APP-LOCAL-SECOND-CORE
101
+ *
102
+ * That is a false NEGATIVE on the commonest tree there is — a second core in
103
+ * the app's own `node_modules` going invisible the moment a developer exports
104
+ * `NODE_PATH` at it. So the rejection was right and the stated reason was not:
105
+ * it is not an equal-but-untyped alternative, it is a narrower one that would
106
+ * have introduced a miss. Generating the walk retires the question entirely —
107
+ * there is no list to screen and no environment read — which is why neither
108
+ * screen survives here.
109
+ *
110
+ * ORDER IS LOAD-BEARING — it is what makes the shadowing case detectable, since
111
+ * the first candidate carrying a core is the one returned. It is Node's own
112
+ * order, verified positionally rather than assumed: a distinct core planted in
113
+ * each of the first four candidates and removed one at a time, `await import`
114
+ * selecting exactly this sequence.
115
+ *
116
+ * `fromDir` must already be realpath'd; `coreSeenBy` does that first.
117
+ */
118
+ export declare function esmNodeModulesWalk(fromDir: string): string[];
119
+ /**
120
+ * The nearest ancestor of `startDir` that OWNS a `package.json`, reported only
121
+ * if that package is `stonyx`.
122
+ *
123
+ * Stops at the first `package.json` rather than at the first one NAMED stonyx:
124
+ * the first is by definition the package that owns the file, and continuing
125
+ * past it would walk out of the resolved package and could report an unrelated
126
+ * ancestor — inside this repo's own worktree, that ancestor is the repo root,
127
+ * which IS named `stonyx`. That would make every fixture look like a match.
128
+ *
129
+ * EXPORTED FOR ITS GUARD. That paragraph is an argument that a behaviour is
130
+ * load-bearing, and until D15 the entire suite could not tell the two
131
+ * behaviours apart — a mutant that walked past a non-stonyx manifest survived
132
+ * every test. A docblock asserting a property with no test that can red is the
133
+ * defect family this cluster exists to remove, so the function is exported for
134
+ * one reason: so that claim can fail.
135
+ */
136
+ export declare function owningCore(startDir: string, report?: InconclusiveReporter): CorePackage | null;
137
+ /** The `stonyx` copy that is executing this code. */
138
+ export declare function runningCore(report?: InconclusiveReporter): CorePackage | null;
139
+ /**
140
+ * The `stonyx` copy a package installed at `moduleDir` would import.
141
+ *
142
+ * The candidate set is `esmNodeModulesWalk` — Node's ESM walk, generated, in
143
+ * Node's order — because ESM is the resolver `loadModules` actually uses. The
144
+ * first candidate that carries a `stonyx` package root wins, which is exactly
145
+ * how PACKAGE_RESOLVE picks. Manifests are read directly rather than through
146
+ * `require.resolve`, so a module whose nested core is present but unbuilt is
147
+ * still detected rather than silently skipped by an `exports` map.
148
+ *
149
+ * ONE deliberate narrowing beyond the walk: `moduleDir` is realpath'd FIRST.
150
+ * Under pnpm, `<app>/node_modules/@stonyx/orm` is a symlink into
151
+ * `.pnpm/@stonyx+orm@v/node_modules/@stonyx/orm`, and Node resolves that
152
+ * symlink before resolving the module's own imports. Walking the symlink path
153
+ * instead reads the app's flat `node_modules` and reports the running core for
154
+ * every module — the check would pass vacuously on exactly the installer
155
+ * `stonyx new` uses.
156
+ *
157
+ * Returns `null` when no copy is reachable at all — "cannot tell", handled as
158
+ * not-a-duplicate by `findForeignCores`. Manifests that exist but will not read
159
+ * go to `report`; see `InconclusiveReporter`.
160
+ */
161
+ export declare function coreSeenBy(moduleDir: string, report?: InconclusiveReporter): CorePackage | null;
162
+ /**
163
+ * Every discovered module that would import a DIFFERENT physical core.
164
+ *
165
+ * FAIL DIRECTION — this is the property, not an implementation detail. A
166
+ * module whose core cannot be resolved, and the case where the running core
167
+ * cannot identify itself, both report NOTHING. This guard exists to convert a
168
+ * silent wrong state into a loud one; it must not invent a boot failure out of
169
+ * an inconclusive probe. Every state it does report has two package roots in
170
+ * hand and has compared them.
171
+ */
172
+ export declare function findForeignCores(modules: {
173
+ name: string;
174
+ dir: string;
175
+ }[], core?: CorePackage | null | undefined, report?: InconclusiveReporter): ForeignCore[];
176
+ /**
177
+ * The diagnostic. It replaces the message abofs/stonyx#108 was filed over —
178
+ * `Stonyx modules with async loading must have a config/environment.js file` —
179
+ * which named a file that was present and correct, and named a module that was
180
+ * not the one that failed.
181
+ *
182
+ * Per `quality.md`, the replacement states what it does NOT cover, because the
183
+ * message it replaces is exactly the kind of overstated claim that made the
184
+ * next reader stop checking.
185
+ */
186
+ export declare function duplicateCoreMessage(foreign: ForeignCore[]): string;