@bobfrankston/npmglobalize 1.0.229 → 1.0.230

package/README.md

@@ -586,6 +586,13 @@ Workspace mode is auto-detected when run from a root with `"private": true` and
                 migration automatically when a build hits a TS7 deprecation
                 error, so day-to-day you never need this flag.
                     npmglobalize <path> -tsfix
+                If the automatic migration breaks a build (usually relative
+                imports missing their .js extension, TS2835), the tsconfig is
+                put back so the build keeps working and EVERY error from the
+                nodenext attempt is listed, file(line,col) and the suggested
+                fix, for fixing by hand. Nothing in the source is rewritten.
+                The migration reruns on the next build once the imports are
+                fixed. (2026-09-14)
 -show           Show package.json dependency changes
 -package, -pkg  Update package.json scripts to use npmglobalize (see below)
 -h, -help       Show help

package/lib.d.ts

@@ -25,6 +25,11 @@ export declare function clearBuildIssues(): void;
 /** Extract the first TypeScript error line from build output for the summary.
  *  Returns a short string like "file.ts(42,5): error TS2339: Property 'foo' ..." */
 export declare function extractFirstTscError(output: string): string | null;
+/** Every TypeScript error line in build output — `file.ts(line,col): error TSnnnn: message`
+ *  — in order, deduplicated, untruncated. For reports where the reader will act on each
+ *  line (the imports a nodenext migration surfaces), as opposed to the one-line summary
+ *  extractFirstTscError gives. (2026-09-14) */
+export declare function extractTscErrors(output: string): string[];
 /** A TS7016 — "Could not find a declaration file for module 'X'" — that tsc blames
  *  on the file being compiled is frequently not that file's fault: the copy of X in
  *  node_modules carries no `.d.ts` whatsoever. That happens when X was published at

package/lib.js

@@ -78,6 +78,24 @@ export function extractFirstTscError(output) {
     }
     return null;
 }
+/** Every TypeScript error line in build output — `file.ts(line,col): error TSnnnn: message`
+ *  — in order, deduplicated, untruncated. For reports where the reader will act on each
+ *  line (the imports a nodenext migration surfaces), as opposed to the one-line summary
+ *  extractFirstTscError gives. (2026-09-14) */
+export function extractTscErrors(output) {
+    if (!output)
+        return [];
+    const seen = new Set();
+    const lines = [];
+    for (const m of output.matchAll(/^(.+?\(\d+,\d+\): error TS\d+: .+)$/gm)) {
+        const line = m[1].trimEnd();
+        if (seen.has(line))
+            continue;
+        seen.add(line);
+        lines.push(line);
+    }
+    return lines;
+}
 /** Does `dir` contain any `.d.ts` at all? Bounded, and never descends into a
  *  nested `node_modules` — we are asking about this package's own output. */
 function hasDeclarationFiles(dir, depth = 3) {
@@ -3753,13 +3771,23 @@ export async function buildProject(cwd, opts = {}) {
             const retry = await runCommandAsync('npm', ['run', 'build'], { cwd, silent: true });
             if (retry.success) {
                 dropBuildIssuesFrom(issueMark); // the migration was undone; its warnings no longer apply
-                const firstErr = extractFirstTscError(migratedOutput);
                 const label = pkg.name || path.basename(cwd);
-                console.log(colors.yellow(`  Reverted the tsconfig TS7 migration in ${label} — it broke the build:`));
-                if (firstErr)
-                    console.log(colors.yellow(`    ${firstErr}`));
-                console.log(colors.yellow(`    Deprecated settings left in place. Fix with: npmglobalize ${cwd} -tsfix`));
-                recordBuildIssue(label, 'warning', `tsconfig still uses settings TypeScript 7 removes: migrating to "nodenext" broke the build (${firstErr || 'see build output'}). Run \`npmglobalize ${cwd} -tsfix\` and fix the surfaced imports.`);
+                // List EVERY error the migrated build produced, not just the first: these
+                // are the imports (usually relative specifiers missing their .js extension)
+                // that have to be fixed by hand before nodenext can stay. The tsconfig is
+                // left on the deprecated settings so the build keeps working meanwhile;
+                // the next build after the imports are fixed migrates again on its own.
+                // 2026-09-14 18:30 EDT — Claude Code (Fable 5.1), at Bob's direction:
+                // "Rather than doing the rewrite of the imports, flag them so I can
+                // manually fix them since I expect most cases have already been fixed."
+                const errs = extractTscErrors(migratedOutput);
+                console.log(colors.yellow(`  Reverted the tsconfig TS7 migration in ${label} — under "nodenext" the build fails on ${errs.length || 'these'} error(s):`));
+                for (const e of errs)
+                    console.log(colors.yellow(`    ${e}`));
+                if (!errs.length)
+                    console.log(colors.yellow(`    ${extractFirstTscError(migratedOutput) || '(no tsc error line found — rerun with -verbose)'}`));
+                console.log(colors.yellow(`    Deprecated settings left in place so the build still works. Fix the imports above; the migration reruns on the next build.`));
+                recordBuildIssue(label, 'warning', `tsconfig still uses settings TypeScript 7 removes: under "nodenext" the build fails on ${errs.length} error(s) (first: ${errs[0] || extractFirstTscError(migratedOutput) || 'see build output'}). Fix the listed imports; the migration reruns on the next build.`);
                 buildResult = retry;
             }
             else {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/npmglobalize",
-  "version": "1.0.229",
+  "version": "1.0.230",
   "description": "Transform file: dependencies to npm versions for publishing",
   "main": "index.js",
   "type": "module",