fix: complete the TypeScript 7 tsconfig migration

The first pass left three classes of config that BOTH tsc 5.9 and tsc 7
reject. Each was proven against both compilers before changing:

  TS5090  A `paths` target must be relative once `baseUrl` is gone. The
          first pass skipped the "./" prefix wherever baseUrl pointed at
          the config's own directory, reasoning it was semantically
          equivalent. It is not — without baseUrl a non-relative target
          is rejected outright, by 5.9 as well as 7.

  TS5110  `moduleResolution: node16` requires `module: node16`. The first
          pass mapped commonjs projects to node16 resolution alone, which
          BROKE those configs for the current toolchain. Both are now set.

  TS5102  `downlevelIteration` is also removed in TS7; it was missing from
          the dead-flag list.

Verified: repos that tsc 7 previously refused (base-studio, js-sdk, kv-js)
now report zero config errors on tsc 7 AND tsc 5.9.

Co-Authored-By: Hanzo Dev <[email protected]>

deploy/tools/envs-validator/tsconfig.json

@@ -1,7 +1,7 @@
 {
 	"compilerOptions": {
 	  "target": "ES2022",
-	  "module": "ESNext",
+	  "module": "node16",
 	  "moduleResolution": "node16",
 	  "esModuleInterop": true,
 	  "strict": true,

deploy/tools/essential-dapps-chains-config-generator/tsconfig.json

@@ -1,7 +1,7 @@
 {
   "compilerOptions": {
     "target": "ES2022",
-    "module": "ESNext",
+    "module": "node16",
     "moduleResolution": "node16",
     "esModuleInterop": true,
     "strict": true,

deploy/tools/llms-txt-generator/tsconfig.json

@@ -1,7 +1,7 @@
 {
   "compilerOptions": {
     "target": "ES2022",
-    "module": "ESNext",
+    "module": "node16",
     "moduleResolution": "node16",
     "esModuleInterop": true,
     "strict": true,

deploy/tools/multichain-config-generator/tsconfig.json

@@ -1,7 +1,7 @@
 {
   "compilerOptions": {
     "target": "ES2022",
-    "module": "ESNext",
+    "module": "node16",
     "moduleResolution": "node16",
     "esModuleInterop": true,
     "strict": true,

tsconfig.json

@@ -21,9 +21,30 @@
     // TS7 removed `baseUrl`, and this project's absolute imports ("configs/app",
     // "lib/api/pchain", "ui/...") were resolved by `baseUrl: "."` alone — `paths`
     // was empty, so dropping baseUrl left nothing to resolve them and tsc could
-    // not typecheck a single file. `"*": ["./*"]` is the same rule expressed the
-    // way TS7 accepts: targets resolve relative to this tsconfig's directory.
-    "paths": { "*": [ "./*" ] },
+    // not typecheck a single file.
+    //
+    // The roots are NAMED, one per source directory, not collapsed into a
+    // `"*": ["./*"]` catch-all. `baseUrl` was a FALLBACK — tried after node
+    // resolution — whereas `paths` takes PRECEDENCE, and every bundler that
+    // reads tsconfig (Turbopack, webpack's tsconfig-paths, Vite) applies it
+    // first. A catch-all therefore captures package specifiers too: Turbopack
+    // rewrote `@luxfi/ui/tooltip` to `./@luxfi/ui/tooltip` inside the project
+    // and the whole app 500'd with "Module not found", because a `paths` miss
+    // is an error, not a fall-through.
+    "paths": {
+      "configs/*": [ "./configs/*" ],
+      "deploy/*": [ "./deploy/*" ],
+      "icons/*": [ "./icons/*" ],
+      "lib/*": [ "./lib/*" ],
+      "mocks/*": [ "./mocks/*" ],
+      "nextjs/*": [ "./nextjs/*" ],
+      "playwright/*": [ "./playwright/*" ],
+      "public/*": [ "./public/*" ],
+      "stubs/*": [ "./stubs/*" ],
+      "toolkit/*": [ "./toolkit/*" ],
+      "types/*": [ "./types/*" ],
+      "ui/*": [ "./ui/*" ]
+    },
     "types": [
       "node"
     ]