stonyx 0.2.3-alpha.56 → 0.2.3-alpha.58

package/README.md

@@ -27,7 +27,7 @@ stonyx test     # Bootstrap + run tests
 stonyx help     # Show all available commands
 ```
 
-Stonyx reads `config/environment.ts` (preferred) or `config/environment.js`, initializes all `@stonyx/*` modules from your `devDependencies`, and runs your application.
+Stonyx reads `config/environment.ts` (preferred) or `config/environment.js`, initializes all `@stonyx/*` modules declared in your `dependencies` or `devDependencies`, and runs your application.
 
 ## Documentation
 

package/dist/modules.js

@@ -18,8 +18,24 @@ function configureLog(chronicle, module, config) {
 function initializeModule(moduleName, moduleClass, modules, initPromises) {
     const moduleInstance = new moduleClass();
     modules.push(moduleInstance);
-    if (!moduleInstance.init)
+    // A module class with no `init()` has nothing to initialise, so it is ready
+    // the moment it is instantiated. Without this its registered promise dangles
+    // — the only resolve on this path lives inside the `init()` wrapper below,
+    // which is never created. Third of the three never-resolved paths named in
+    // #120, and the one that scoping registration to `discovered` does NOT close,
+    // because such a module IS discovered — measured, not reasoned: with only
+    // the registration fix applied the suite read 180/1 with T24 the sole
+    // failure. Resolving here is truthful, because the module really did load,
+    // and that is what separates it from resolving on a discovery `continue`,
+    // where there is no module to be ready.
+    //
+    // `?.` for the reason the resolve below carries it: `initializeModule` is
+    // also reached from the standalone path as `initializeModule(projectName, …)`,
+    // and `projectName` is never a key in `modulePromises`.
+    if (!moduleInstance.init) {
+        modulePromises[moduleName]?.resolve();
         return;
+    }
     initPromises.push((async () => {
         await moduleInstance.init();
         modulePromises[moduleName]?.resolve();
@@ -78,17 +94,35 @@ export default async function loadModules(config, rootPath, chronicle) {
     const modules = [];
     const initPromises = [];
     const rootPackage = await readFile(`${rootPath}/package.json`, { json: true });
-    const dependencies = (rootPackage.devDependencies || {});
+    // DISCOVERY SOURCE (abofs/stonyx#106 rule 3).
+    //
+    // This local used to be named `dependencies` while holding `devDependencies`
+    // and nothing else. That name is the ruled root cause of #106: every reader
+    // of this function — including its own docs — believed discovery scanned
+    // both maps, because the identifier said so. It did not. An installed stonyx
+    // module declared in `dependencies` was invisible, which is precisely how the
+    // published fleet pins the core, so the loader could not see its own
+    // siblings.
+    //
+    // Rule 3 widens the source to the DE-DUPLICATED union of both maps. Object
+    // spread IS the de-duplication and is load-bearing: a module declared in both
+    // maps collapses to one key, so it is registered once and instantiated once.
+    // A bare `[ ...Object.keys(deps), ...Object.keys(devDeps) ]` concat produces a
+    // byte-identical suite aggregate while instantiating such a module twice and
+    // running its `init()` twice — T22's instance-count assertion owns that kill.
+    const declaredDependencies = {
+        ...(rootPackage.dependencies || {}),
+        ...(rootPackage.devDependencies || {}),
+    };
     const projectName = typeof rootPackage.name === 'string' ? rootPackage.name : '';
     // Expose rootPath to public configuration
     config.rootPath = rootPath;
-    const moduleDependencies = Object.keys(dependencies).filter((moduleName) => moduleName.startsWith('@stonyx/'));
-    // Setup module promises prior to initialization
-    for (const moduleName of moduleDependencies) {
-        const promise = {};
-        modulePromises[moduleName] = promise;
-        promise.ready = new Promise(resolve => promise.resolve = resolve);
-    }
+    // The `@stonyx/` prefix filter STAYS (#106 keeps it explicitly). Widening it
+    // to `@` — or dropping it — makes the loader warn on every non-Stonyx
+    // dependency and leaves their `modulePromises` entries permanently
+    // unresolved. T3 owns that kill. What is a module is decided below, by the
+    // `stonyx-module` keyword; this is only a name test that bounds the scan.
+    const moduleDependencies = Object.keys(declaredDependencies).filter((moduleName) => moduleName.startsWith('@stonyx/'));
     // DISCOVERY, hoisted above the pre-flight.
     //
     // The pre-flight must check exactly what the loader loads, and no more.
@@ -119,6 +153,41 @@ export default async function loadModules(config, rootPath, chronicle) {
             keywords,
         });
     }
+    // Setup module promises prior to initialization — over `discovered`, NOT
+    // over `moduleDependencies`.
+    //
+    // This loop used to run above discovery and consume the declared list. That
+    // was already the shape at base, but rule 3 widened what the declared list
+    // contains, and the widening turned a fast named throw into an unbounded
+    // boot hang. A name registered here but never resolved leaves
+    // `waitForModule` pending forever; discovery `continue`s past two kinds of
+    // name without reaching either of this file's two resolve sites — a manifest
+    // that is not there, and a package without the `stonyx-module` keyword.
+    // `@stonyx/logs` ships without that keyword and is an ordinary `dependencies`
+    // entry, so this is a shape the fleet actually has.
+    //
+    //   name in `dependencies`, not installed, another module awaits it
+    //     base 5693744  throws "…was not registered in project dependencies", 3 ms
+    //     a57045e       one console.warn, then loadModules never settles
+    //
+    // Registering only what discovery admitted restores the fail-fast for both,
+    // and for `devDependencies`-declared names too — that half is INHERITED, not
+    // introduced here, and it is a real behaviour change: hang becomes throw.
+    // T13 pins it, and the PR body names it.
+    //
+    // The alternative — resolving in each `continue` branch — also removes the
+    // hang and is worse: `waitForModule` would report success for a module that
+    // was never loaded, silently. T23 asserts the named rejection precisely so
+    // that remedy cannot pass.
+    //
+    // Ordering is safe: nothing between here and the old site touches
+    // `modulePromises`, discovery only reads manifests, and registration still
+    // completes before the first `init()` can run.
+    for (const { name: moduleName } of discovered) {
+        const promise = {};
+        modulePromises[moduleName] = promise;
+        promise.ready = new Promise(resolve => promise.resolve = resolve);
+    }
     // Pre-flight: invariant I1, "one core". Before ANY module entry point is
     // imported, because the point of the check is the module that would NOT
     // throw — it would load, initialise, and register its hooks on a second

package/package.json

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