@dudousxd/nestjs-codegen 0.21.0 → 0.21.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,69 @@
1
1
  # @dudousxd/nestjs-codegen
2
2
 
3
+ ## 0.21.1
4
+
5
+ ### Patch Changes
6
+
7
+ - da3c66c: Load the consumer tsconfig without walking their file tree, and stop falling back from it in silence
8
+
9
+ `createDiscoveryProject` handed `tsConfigFilePath` to ts-morph and wrapped the
10
+ call in a bare `try/catch` that, on ANY error, rebuilt the `Project` with no
11
+ tsconfig at all. Both halves of that were a problem.
12
+
13
+ Parsing a tsconfig also resolves its FILE LIST, and a tsconfig with no `include`
14
+ defaults to `**/*` — so TypeScript walks every directory under the project root.
15
+ One directory the codegen process cannot read is enough to throw
16
+ `EACCES: permission denied, scandir ...` and take the whole tsconfig down with
17
+ it; a docker bind mount that a container has chowned to its own UID with
18
+ mode-700 subdirs (Grafana, Prometheus, MinIO, a DB data dir) is exactly that
19
+ shape. `skipAddingFilesFromTsConfig` did not help, because it discards the file
20
+ list only after it has been computed.
21
+
22
+ Discovery never wanted that list — only `paths`/`baseUrl`/`target`/decorator
23
+ flags — so the tsconfig is now read through `ts.readConfigFile` +
24
+ `ts.parseJsonConfigFileContent` with a host whose `readDirectory` returns
25
+ nothing, and the parsed options are passed to `new Project({ compilerOptions })`.
26
+ No directory is read, so no unreadable one can matter. `extends` still resolves,
27
+ and passing the parsed options through wholesale preserves TypeScript's
28
+ `pathsBasePath` (how `paths` resolves when the tsconfig sets no `baseUrl`).
29
+
30
+ The silent fallback is what made this expensive to diagnose. A `Project` with no
31
+ tsconfig has no `paths`, and go-to-definition is how a factory-based controller
32
+ (`class X extends createTableController(...)`) is resolved — so an
33
+ alias-imported factory stops resolving and every route those controllers
34
+ contribute disappears from the generated client. The only output was the
35
+ per-controller `contributes NO routes` warning, which blames the controller. A
36
+ tsconfig that exists but cannot be loaded now warns once, naming the tsconfig,
37
+ the underlying error and what it costs. A MISSING tsconfig stays silent: relative
38
+ imports need no `paths`, so a tsconfig-less consumer is a supported setup.
39
+
40
+ Measured against a real consumer with one unreadable directory in its root:
41
+ 313 routes and 0 factory-derived routes with 22 `contributes NO routes`
42
+ warnings, versus 357 routes and 44 factory-derived routes with none.
43
+
44
+ Also folds the tsconfig into the generate manifest's input hash. The freshness
45
+ check ("up to date, skipped") did not cover it, so a tsconfig that made discovery
46
+ generate a WRONG artifact left that artifact on disk after the tsconfig was
47
+ fixed, and every later run skipped over it — the only way out was deleting
48
+ `.codegen-manifest.json` by hand. Raw contents are hashed rather than the
49
+ resolved options, because `include`/`exclude` are not compiler options and an
50
+ added `exclude` is exactly what such a fix tends to be. The whole `extends` chain
51
+ is hashed, not just the entry file, since that is where a shared `paths` block
52
+ usually lives.
53
+
54
+ Two things follow from loading the tsconfig properly, both previously wrong in the
55
+ same direction — an alias that silently resolved to nothing:
56
+
57
+ - `paths` now come from that single load, so a mapping declared in a tsconfig
58
+ reached through `extends` is finally seen. The old reader parsed the entry
59
+ file's raw JSON itself, so it saw neither `extends` nor block comments, and it
60
+ could disagree with the options the `Project` was built from.
61
+ - Those mappings resolve the way `tsc` resolves them — against `baseUrl` when
62
+ set, else against the directory of the file that DECLARED them (TypeScript's
63
+ `pathsBasePath`). They were resolved against the project root, which is not the
64
+ same directory for a `paths` block inherited from `config/base.json`, or for a
65
+ `baseUrl` of `./src`.
66
+
3
67
  ## 0.21.0
4
68
 
5
69
  ### Minor Changes