src/entity-schema/EntitySchemaOptions.ts (1)

140-141: Clarify API semantics: document that only a single tree strategy is supported per entity

Decorator-based entities only support one @Tree(...) per entity. The plural shape (trees: []) is OK for consistency with other arrays, but without guidance it invites multiple entries, which would be undefined behavior. At minimum, add JSDoc that this array must contain at most one element and is equivalent to @Tree(...).

Apply this diff to document intent:

-    trees?: Omit<TreeMetadataArgs, "target">[]
+    /**
+     * Tree configuration for this entity (equivalent to using `@Tree(...)`).
+     * Note: only a single tree strategy is supported per entity; provide at most one entry.
+     */
+    trees?: Omit<TreeMetadataArgs, "target">[]

src/entity-schema/EntitySchemaTransformer.ts (1)

400-408: Enforce single tree per entity; optional: emit tree metadata at top-level (not during embedded recursion)

Registering tree metadata is correct. Two improvements:

• Prevent multiple tree strategies on a single entity (only one is supported).
• Optional: consider moving this block to the top-level transform (alongside table/ inheritance) to avoid accidental emission from embeddeds if someone mistakenly places trees on an embedded schema.

Apply this guard to avoid multiple entries:

-        if (options.trees) {
-            options.trees.forEach((tree) => {
+        if (options.trees) {
+            if (options.trees.length > 1) {
+                throw new Error(
+                    `Only one tree strategy is supported per entity schema (${String(
+                        options.target || options.name,
+                    )}).`,
+                )
+            }
+            options.trees.forEach((tree) => {
                 metadataArgsStorage.trees.push({
                     target: options.target || options.name,
                     type: tree.type,
                     options: tree.options,
                 })
             })
         }

If you prefer, I can follow up with a small refactor to move this emission to transform(), right after pushing the table metadata.

test/functional/entity-schema/trees/nested-set/entity/Category.ts (2)

21-31: Add inverseSide to make relations explicit and self-documenting

Tree-specific flags work, but adding inverseSide reduces ambiguity and matches patterns used elsewhere in the codebase.

Apply this diff:

         parentCategory: {
             type: "many-to-one",
             treeParent: true,
             target: "Category",
+            inverseSide: "childCategories",
         },
         childCategories: {
             type: "one-to-many",
             treeChildren: true,
             target: "Category",
             cascade: true,
+            inverseSide: "parentCategory",
         },

---

3-8: Improve typings to avoid any (optional)

Using any/any[] here works for tests but loses type-safety. Consider introducing a small model type to keep generics aligned without colliding with the exported constant name.

For example:

type CategoryModel = {
  id: number
  name: string
  parentCategory: CategoryModel | null
  childCategories: CategoryModel[]
}

export const Category = new EntitySchema<CategoryModel>({ /* ... */ })

test/functional/entity-schema/trees/nested-set/nested-set.ts (1)

23-68: Solid happy-path coverage; consider adding a negative test for multiple roots

The flow validates roots/ancestors/descendants and exercises the new schema-based tree metadata. To match decorator-based coverage, consider adding a test asserting that saving a second root is rejected for nested-set trees.

You can append a separate spec:

it("should reject multiple roots for nested-set", () =>
  Promise.all(
    connections.map(async (connection) => {
      const repo = connection.getTreeRepository(Category)

      const a1 = await repo.save({ name: "a1" })
      // Attempt a second root
      await repo
        .save({ name: "b1" })
        .then(() => {
          throw new Error("expected rejection for multiple roots")
        })
        .catch((err) => {
          err.message.should.match(/Nested sets do not support multiple root entities/i)
        })
    }),
  ))

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled
• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

src/entity-schema/EntitySchemaOptions.ts (1)

139-141: Prefer a singular tree option (one tree per entity).

Decorator parity: entities support exactly one tree type. An array invites invalid configs (multiple entries). Recommend a singular property and adjust the transformer accordingly.

Apply:

-  trees?: Omit<TreeMetadataArgs, "target">[]
+  /**
+   * Tree configuration for this entity (e.g. "closure-table", "nested-set", "materialized-path").
+   */
+  tree?: Omit<TreeMetadataArgs, "target">

If keeping trees for backward symmetry with array-based options, at least validate length ≤ 1 in the transformer and use the first entry.

Would you confirm whether multiple trees per entity are intended? If not, I can provide a follow-up patch to enforce a single entry.

src/entity-schema/EntitySchemaTransformer.ts (1)

400-408: Enforce a single tree and simplify handling.

Current code allows multiple trees and processes within the recursive path. Recommend:

• Use a singular option and push once, avoiding embedded schemas.

If adopting tree (singular), change this block to:

-        if (options.trees) {
-            options.trees.forEach((tree) => {
-                metadataArgsStorage.trees.push({
-                    target: options.target || options.name,
-                    type: tree.type,
-                    options: tree.options,
-                })
-            })
-        }
+        if (options.tree) {
+            metadataArgsStorage.trees.push({
+                target: options.target || options.name,
+                type: options.tree.type,
+                options: options.tree.options,
+            })
+        }

If keeping an array, minimally guard against multiple entries and ignore/throw on extras; also consider moving this logic to the top-level transform (non-recursive) to prevent accidental registration from embeddeds.

Please confirm whether we should (a) reject multiple entries or (b) accept only the first. I can supply a precise patch for either path.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro