@dudousxd/nestjs-codegen 0.21.1 → 0.22.1

package/CHANGELOG.md

@@ -1,5 +1,55 @@
 # @dudousxd/nestjs-codegen
 
+## 0.22.1
+
+### Patch Changes
+
+- da8ec39: Order routes by file path, so an unchanged source tree always generates the same client
+
+  Route order decided the order of everything emitted from it — the groups in
+  `api.ts`, the entries in `routes.ts` — and it was whatever order discovery
+  happened to reach the files in. The cold path adds controllers in `fast-glob`'s
+  directory-walk order, which is I/O-completion order from a concurrent walk: it
+  holds while the FS cache is warm and can differ on a cold one, so regenerating
+  an untouched project could move a controller group to a different position. The
+  watcher appended each newly-created controller to the end of its set, so from
+  the moment a file was added its output no longer matched a cold run's, for the
+  rest of the session.
+
+  Both extraction entry points now sort their roots by path. `discoverPages` has
+  sorted its glob from the start, which is why only the controller-derived
+  artifacts ever moved.
+
+  Nothing about the generated client changes except the order of its blocks —
+  same routes, same types, same members. Consumers who commit their generated
+  directory should expect one reorder-only diff on the first run after upgrading.
+
+## 0.22.0
+
+### Minor Changes
+
+- 4af626a: Hand extensions the tsconfig-seeded Project instead of making each build its own
+
+  `ExtensionContext` gains `tsconfigProject()`: a lazily-created, memoized ts-morph
+  `Project` built from the consumer's tsconfig (`app.tsconfig`, else
+  `<cwd>/tsconfig.json`), so `paths` aliases resolve. `project()` is unchanged — it
+  stays the bare, paths-less scratch project — and the two are now documented against
+  each other.
+
+  An extension that needs to follow a `@/api/...` import from a controller to the
+  decorator target it reads had no way to get one, so it built its own from
+  `tsConfigFilePath`. That has a trap: parsing a tsconfig also resolves its FILE LIST,
+  and a tsconfig with no `include` walks the entire project root, so one unreadable
+  directory (a docker bind mount a container chowned to its own UID) throws
+  `EACCES ... scandir`. Every hand-rolled copy then fell back to a paths-less Project
+  in silence, and aliased targets resolved to nothing with no error anywhere — the
+  same bug, once per extension. The host now loads it correctly, once, and hands it
+  out; N extensions share one parse instead of one each.
+
+  Typed as optional (`tsconfigProject?()`) on purpose: an extension may run against an
+  older host that does not provide it, so the ecosystem pattern is
+  `ctx.tsconfigProject?.() ?? <own fallback>`.
+
 ## 0.21.1
 
 ### Patch Changes