stonyx 0.2.3-alpha.47 → 0.2.3-alpha.48

package/README.md

@@ -22,7 +22,7 @@ stonyx serve
 The `new` command walks you through module selection and generates a ready-to-run project. From there, the CLI handles bootstrapping:
 
 ```bash
-stonyx serve    # Bootstrap + run app.js
+stonyx serve    # Bootstrap + run app.ts (or app.js)
 stonyx test     # Bootstrap + run tests
 stonyx help     # Show all available commands
 ```

package/dist/cli/help.js

@@ -23,8 +23,8 @@ export default async function help({ args, builtInCommands, loadModuleCommands }
     }
     console.log('\nAliases: s=serve, t=test, n=new, h=help\n');
     console.log('Project conventions:\n');
-    console.log('  Entry point:       app.js');
-    console.log('  Config:            config/environment.js');
+    console.log('  Entry point:       app.ts (or app.js)');
+    console.log('  Config:            config/environment.ts (or .js)');
     console.log('  DB schema:         config/db-schema.js');
     console.log('  Models:            models/');
     console.log('  Serializers:       serializers/');

package/dist/util/import-config.d.ts

@@ -18,4 +18,26 @@ export declare const CONFIG_NOT_FOUND_PREFIX = "Config not found:";
  * both produced the byte-identical `Config not found: .../config/environment.js`.
  */
 export declare const CONFIG_NOT_LOADABLE_PREFIX = "Config present but not loadable:";
+/**
+ * Did this runtime refuse OUR config file, or something our config imported?
+ *
+ * `FILE_TYPE_REFUSAL_CODES.has(code)` alone cannot tell. A config that loaded
+ * and ran perfectly well, but whose own nested `import()` hit a `.ts` under
+ * `node_modules`, throws the SAME code — and was reported as "this Node runtime
+ * refused to load your config", naming a file that is fine. That misdirection
+ * points the consumer at the one file that is not the problem, and the likeliest
+ * instance of it is the exact `.ts`-under-node_modules case this loader's own
+ * docs tell people to look for.
+ *
+ * Returns true when the refusal names our path, or when no path could be
+ * extracted at all (unknown message shape — keep re-framing rather than
+ * silently losing the loud error that invariant I2 exists for).
+ *
+ * Exported ONLY so its branches can be reached directly. Driving it through
+ * `importConfig` reaches the two path-comparison outcomes and nothing else:
+ * the "no path extractable" fallback and the `realPath` catch both survived
+ * mutation with the suite green. A predicate inside the guard that makes
+ * failures loud does not get to have branches no test can reach.
+ */
+export declare function refusalIsAboutTheConfig(message: string, configPath: string): boolean;
 export declare function importConfig<T = unknown>(basePath: string): Promise<T>;

package/dist/util/import-config.js

@@ -1,5 +1,5 @@
-import { existsSync } from 'fs';
-import { pathToFileURL } from 'url';
+import { existsSync, realpathSync } from 'fs';
+import { fileURLToPath, pathToFileURL } from 'url';
 /**
  * Extensions `importConfig` will load, in preference order.
  *
@@ -18,10 +18,18 @@ import { pathToFileURL } from 'url';
  */
 const LOADABLE_EXTENSIONS = ['ts', 'js'];
 /**
- * Extensions a consumer plausibly writes a config as, that this loader will not
- * read. Their only purpose is to be DETECTED: see `CONFIG_NOT_LOADABLE_PREFIX`.
+ * Extensions a consumer plausibly writes a config as, that this loader does not
+ * RESOLVE. Their only purpose is to be DETECTED: see `CONFIG_NOT_LOADABLE_PREFIX`.
+ *
+ * Named for what is actually true of them. `.mjs`, `.cjs` and `.json` are all
+ * perfectly readable by Node — `import()` handles every one of them today.
+ * Nothing here is unreadable; they are simply not in `LOADABLE_EXTENSIONS`, so
+ * this loader never forms a path with them, and a consumer who writes one gets
+ * "config present but not loadable" instead of a silent "not found". The old
+ * name, UNREADABLE_EXTENSIONS, asserted a property of Node that is false, and
+ * invited a future reader to "fix" it by adding them to the resolver.
  */
-const UNREADABLE_EXTENSIONS = ['mts', 'cts', 'tsx', 'jsx', 'mjs', 'cjs', 'json'];
+const UNRESOLVED_EXTENSIONS = ['mts', 'cts', 'tsx', 'jsx', 'mjs', 'cjs', 'json'];
 /**
  * "There is no config here." Callers are allowed to treat this as benign —
  * `src/main.ts` does, for the optional `test/config/environment.*` override.
@@ -58,10 +66,69 @@ const FILE_TYPE_REFUSAL_CODES = new Set([
     'ERR_UNKNOWN_FILE_EXTENSION',
     'ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING',
 ]);
+/**
+ * The first absolute POSIX path named in a Node error message.
+ *
+ * Both refusal codes name the file they refused, but in different shapes —
+ * measured on node v24.13.0:
+ *
+ *   ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING
+ *     Stripping types is currently unsupported for files under node_modules,
+ *     for "/private/tmp/x/node_modules/dep/thing.ts"
+ *   ERR_UNKNOWN_FILE_EXTENSION
+ *     Unknown file extension ".ts" for /private/tmp/x/environment.ts
+ *
+ * The second names a bare extension BEFORE it names the file, which is why
+ * this requires a leading `/` rather than matching the first quoted token.
+ * Neither error exposes the path as an own property: `Object.keys(error)` is
+ * `['code']` for both, so the message is the only source.
+ *
+ * Deliberately POSIX-only. A Windows path is simply not extracted, and
+ * `refusalIsAboutTheConfig` treats "no path extracted" as "cannot tell" and
+ * keeps the pre-existing behaviour, so this degrades rather than misfires.
+ */
+const REFUSED_PATH_PATTERN = /(?:^|[\s"'(])((?:file:\/\/)?\/[^\s"'()]+\.[A-Za-z0-9]+)/;
+/** Resolves symlinks so `/tmp/...` and `/private/tmp/...` compare equal. */
+function realPath(path) {
+    try {
+        return realpathSync(path);
+    }
+    catch {
+        return path;
+    }
+}
+/**
+ * Did this runtime refuse OUR config file, or something our config imported?
+ *
+ * `FILE_TYPE_REFUSAL_CODES.has(code)` alone cannot tell. A config that loaded
+ * and ran perfectly well, but whose own nested `import()` hit a `.ts` under
+ * `node_modules`, throws the SAME code — and was reported as "this Node runtime
+ * refused to load your config", naming a file that is fine. That misdirection
+ * points the consumer at the one file that is not the problem, and the likeliest
+ * instance of it is the exact `.ts`-under-node_modules case this loader's own
+ * docs tell people to look for.
+ *
+ * Returns true when the refusal names our path, or when no path could be
+ * extracted at all (unknown message shape — keep re-framing rather than
+ * silently losing the loud error that invariant I2 exists for).
+ *
+ * Exported ONLY so its branches can be reached directly. Driving it through
+ * `importConfig` reaches the two path-comparison outcomes and nothing else:
+ * the "no path extractable" fallback and the `realPath` catch both survived
+ * mutation with the suite green. A predicate inside the guard that makes
+ * failures loud does not get to have branches no test can reach.
+ */
+export function refusalIsAboutTheConfig(message, configPath) {
+    const refused = REFUSED_PATH_PATTERN.exec(message)?.[1];
+    if (!refused)
+        return true;
+    const refusedPath = refused.startsWith('file://') ? fileURLToPath(refused) : refused;
+    return refusedPath === configPath || realPath(refusedPath) === realPath(configPath);
+}
 export async function importConfig(basePath) {
     const matches = LOADABLE_EXTENSIONS.filter(ext => existsSync(`${basePath}.${ext}`));
     if (matches.length === 0) {
-        const declined = UNREADABLE_EXTENSIONS.filter(ext => existsSync(`${basePath}.${ext}`));
+        const declined = UNRESOLVED_EXTENSIONS.filter(ext => existsSync(`${basePath}.${ext}`));
         if (declined.length > 0) {
             throw new Error(`${CONFIG_NOT_LOADABLE_PREFIX} ${basePath}.${declined.join(` and ${basePath}.`)} ` +
                 `exists, but Stonyx loads ${basePath}.ts or ${basePath}.js only. ` +
@@ -79,12 +146,29 @@ export async function importConfig(basePath) {
     }
     catch (error) {
         const code = error?.code;
-        if (code && FILE_TYPE_REFUSAL_CODES.has(code)) {
+        if (code && FILE_TYPE_REFUSAL_CODES.has(code) && refusalIsAboutTheConfig(error.message, path)) {
+            // Both files exist AND the `.ts` was refused. This is the one state where
+            // the both-present warning printed a few lines above is actively wrong
+            // advice: it says "delete the .js", and here the `.js` is the only file
+            // this runtime can read. Say so explicitly rather than leaving the
+            // consumer to reconcile two messages from the same call.
+            //
+            // It is also a deliberate behaviour change. `stonyx@0.2.3-beta.95`
+            // resolved `${basePath}.js` unconditionally, so this exact state LOADED
+            // and booted; measured against that loader, same fixture, plain node:
+            // it returned the `.js` default export with no warning. Preferring `.ts`
+            // is the point of #105, and the population most likely to hold both
+            // files is the one that worked around #105 by renaming to `.js` while
+            // the postinstall kept writing the `.ts` stub. So this message has to
+            // carry the "this used to work" fact, not just the remedy.
             const sibling = matches.length > 1
-                ? ` A ${basePath}.js also exists; .ts wins by design, so this is not resolved by leaving the .js in place.`
+                ? ` ${basePath}.js also exists and this runtime CAN read it, but .ts wins the preference order` +
+                    ` so the .js is never reached. Disregard the "delete the .js" warning above — in THIS state the` +
+                    ` fix is the opposite one: remove or compile ${basePath}.ts.` +
+                    ` (stonyx@0.2.3-beta.95 loaded the .js here; preferring .ts is a deliberate change — abofs/stonyx#105.)`
                 : '';
             throw new Error(`${CONFIG_NOT_LOADABLE_PREFIX} ${path} exists, but this Node runtime refused to load it ` +
-                `(${code}): ${error.message}${sibling}`, { cause: error });
+                `(${code}): ${error.message}.${sibling}`, { cause: error });
         }
         throw error;
     }

package/package.json

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