stonyx 0.2.3-alpha.8 → 0.2.3-alpha.80
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.
- package/README.md +32 -7
- package/config/{environment.js → environment copy.ts } +16 -12
- package/dist/cli/help.d.ts +8 -0
- package/dist/cli/help.js +43 -0
- package/dist/cli/load-commands.d.ts +10 -0
- package/dist/cli/load-commands.js +49 -0
- package/dist/cli/new.d.ts +72 -0
- package/dist/cli/new.js +422 -0
- package/dist/cli/serve.d.ts +6 -0
- package/dist/cli/serve.js +49 -0
- package/dist/cli/test-setup.d.ts +1 -0
- package/dist/cli/test-setup.js +30 -0
- package/dist/cli/test.d.ts +4 -0
- package/dist/cli/test.js +23 -0
- package/dist/cli.d.ts +2 -0
- package/dist/cli.js +53 -0
- package/dist/exports/config.d.ts +2 -0
- package/dist/exports/config.js +2 -0
- package/dist/exports/log.d.ts +2 -0
- package/{src → dist}/exports/log.js +1 -2
- package/dist/exports/test-helpers.d.ts +5 -0
- package/dist/exports/test-helpers.js +7 -0
- package/dist/lifecycle.d.ts +7 -0
- package/dist/lifecycle.js +18 -0
- package/dist/main.d.ts +22 -0
- package/dist/main.js +102 -0
- package/dist/modules.d.ts +5 -0
- package/dist/modules.js +186 -0
- package/dist/util/duplicate-core.d.ts +186 -0
- package/dist/util/duplicate-core.js +377 -0
- package/dist/util/import-config.d.ts +52 -0
- package/dist/util/import-config.js +256 -0
- package/dist/util/resolve-entry-point.d.ts +1 -0
- package/dist/util/resolve-entry-point.js +14 -0
- package/dist/util/resolve-module-name.d.ts +14 -0
- package/dist/util/resolve-module-name.js +33 -0
- package/package.json +41 -12
- package/scripts/postinstall-manifest.js +16 -0
- package/scripts/postinstall.js +17 -2
- package/.claude/index.md +0 -96
- package/.github/workflows/ci.yml +0 -16
- package/.github/workflows/publish.yml +0 -51
- package/docs/api.md +0 -89
- package/docs/cli.md +0 -78
- package/docs/configuration.md +0 -72
- package/docs/conventions/cron-conventions.md +0 -195
- package/docs/conventions/discord-conventions.md +0 -62
- package/docs/conventions/framework-modules.md +0 -140
- package/docs/conventions/index.md +0 -25
- package/docs/conventions/orm-conventions.md +0 -190
- package/docs/conventions/project-structure.md +0 -105
- package/docs/conventions/rest-conventions.md +0 -96
- package/docs/conventions/testing-conventions.md +0 -56
- package/docs/developing-modules.md +0 -108
- package/docs/index.md +0 -15
- package/docs/lifecycle.md +0 -47
- package/docs/logging.md +0 -52
- package/docs/modules.md +0 -78
- package/docs/testing.md +0 -64
- package/src/cli/help.js +0 -48
- package/src/cli/load-commands.js +0 -56
- package/src/cli/new.js +0 -237
- package/src/cli/serve.js +0 -38
- package/src/cli/test-setup.js +0 -8
- package/src/cli/test.js +0 -27
- package/src/cli.js +0 -63
- package/src/exports/config.js +0 -3
- package/src/exports/test-helpers.js +0 -8
- package/src/lifecycle.js +0 -17
- package/src/main.js +0 -101
- 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>;
|
package/dist/modules.js
ADDED
|
@@ -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;
|