stonyx 0.2.3-alpha.56 → 0.2.3-alpha.57

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

@@ -78,11 +78,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/'));
+    // 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/'));
     // Setup module promises prior to initialization
     for (const moduleName of moduleDependencies) {
         const promise = {};

package/package.json

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