stonyx 0.2.3-alpha.55 → 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/dist/util/duplicate-core.d.ts

@@ -47,10 +47,13 @@ export type InconclusiveReporter = (message: string) => void;
  * mode rather than screening for it — nothing here reads the environment, so
  * there is no list to get the screen wrong on.
  *
- * TOO NARROW, and this one was a SILENT MISS. `require.resolve.paths` is
- * `Module._nodeModulePaths`, which never descends into a directory already
- * named `node_modules`. **ESM's PACKAGE_RESOLVE has no such skip.** Measured
- * with no `NODE_PATH` at all, from a module at `<app>/node_modules/@stonyx/x`:
+ * TOO NARROW, and this one was a SILENT MISS. WHICH CJS ENUMERATION IS MEANT
+ * IS PART OF THE CLAIM, because the two are not the same set: the walk PROPER
+ * is `Module._nodeModulePaths`, and `require.resolve.paths` is that walk
+ * FOLLOWED BY the global folders of the paragraph above. It is the walk proper
+ * that never descends into a directory already named `node_modules`. **ESM's
+ * PACKAGE_RESOLVE has no such skip.** Measured with no `NODE_PATH` at all,
+ * from a module at `<app>/node_modules/@stonyx/x`:
  *
  *   import.meta.resolve('stonyx') -> <app>/node_modules/node_modules/stonyx/main.js
  *   await import('stonyx')        -> that copy
@@ -64,6 +67,18 @@ export type InconclusiveReporter = (message: string) => void;
  * written to catch it. Isolating control, moving nothing but the directory: the
  * same core at `<app>/node_modules/@stonyx/x/node_modules/stonyx` was REFUSED.
  *
+ * THE SET DELTA, both directions and named per enumeration — node v24.13.0,
+ * from that same module dir. Against the WALK PROPER the difference is one
+ * directory and it is one-sided: `esm \ Module._nodeModulePaths` = exactly
+ * `<app>/node_modules/node_modules` (the miss above), and
+ * `Module._nodeModulePaths \ esm` = `[]`. Against `require.resolve.paths` the
+ * second direction is NOT empty and never was: `require.resolve.paths \ esm` =
+ * the three global folders (measured here: `~/.node_modules`,
+ * `~/.node_libraries` and the node prefix, all three absent on disk) PLUS one
+ * entry per `NODE_PATH` component, four more as this workspace exports it. That tail IS the "too wide" defect above, measured rather than
+ * argued, and it is why an unqualified "the CJS candidates are the same" is
+ * true of one enumeration and false of the other.
+ *
  * BOUNDED BY ANCESTRY, not by a rule. `<app>/node_modules/node_modules` is a
  * candidate because `<app>/node_modules` is an ancestor of the module dir; two
  * levels of nesting is not a candidate, because

package/dist/util/duplicate-core.js

@@ -56,10 +56,13 @@ const IGNORE = () => { };
  * mode rather than screening for it — nothing here reads the environment, so
  * there is no list to get the screen wrong on.
  *
- * TOO NARROW, and this one was a SILENT MISS. `require.resolve.paths` is
- * `Module._nodeModulePaths`, which never descends into a directory already
- * named `node_modules`. **ESM's PACKAGE_RESOLVE has no such skip.** Measured
- * with no `NODE_PATH` at all, from a module at `<app>/node_modules/@stonyx/x`:
+ * TOO NARROW, and this one was a SILENT MISS. WHICH CJS ENUMERATION IS MEANT
+ * IS PART OF THE CLAIM, because the two are not the same set: the walk PROPER
+ * is `Module._nodeModulePaths`, and `require.resolve.paths` is that walk
+ * FOLLOWED BY the global folders of the paragraph above. It is the walk proper
+ * that never descends into a directory already named `node_modules`. **ESM's
+ * PACKAGE_RESOLVE has no such skip.** Measured with no `NODE_PATH` at all,
+ * from a module at `<app>/node_modules/@stonyx/x`:
  *
  *   import.meta.resolve('stonyx') -> <app>/node_modules/node_modules/stonyx/main.js
  *   await import('stonyx')        -> that copy
@@ -73,6 +76,18 @@ const IGNORE = () => { };
  * written to catch it. Isolating control, moving nothing but the directory: the
  * same core at `<app>/node_modules/@stonyx/x/node_modules/stonyx` was REFUSED.
  *
+ * THE SET DELTA, both directions and named per enumeration — node v24.13.0,
+ * from that same module dir. Against the WALK PROPER the difference is one
+ * directory and it is one-sided: `esm \ Module._nodeModulePaths` = exactly
+ * `<app>/node_modules/node_modules` (the miss above), and
+ * `Module._nodeModulePaths \ esm` = `[]`. Against `require.resolve.paths` the
+ * second direction is NOT empty and never was: `require.resolve.paths \ esm` =
+ * the three global folders (measured here: `~/.node_modules`,
+ * `~/.node_libraries` and the node prefix, all three absent on disk) PLUS one
+ * entry per `NODE_PATH` component, four more as this workspace exports it. That tail IS the "too wide" defect above, measured rather than
+ * argued, and it is why an unqualified "the CJS candidates are the same" is
+ * true of one enumeration and false of the other.
+ *
  * BOUNDED BY ANCESTRY, not by a rule. `<app>/node_modules/node_modules` is a
  * candidate because `<app>/node_modules` is an ancestor of the module dir; two
  * levels of nesting is not a candidate, because

package/package.json

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