Follow-up from PR #522 (#444).
extractMethodTypes (packages/core/src/scripts/extract-ts-types.ts) attributes a factory-returned ApiNamespace to its namespace only for a top-level identifier or a shallow object binding pattern. Array/tuple patterns and nested destructuring fall through to the bare-key path:
const [ns] = factory(); // array/tuple pattern → bare key only
const { a: { b } } = factory(); // nested → bare key onlyToday this is fail-soft: the schema is still recovered under the bare method name, and generate-spec's #498 fallback resolves it when there is no method-name collision. But if a factory returns a tuple of namespaces with a colliding method name (e.g. const [a, b] = factory() where both expose create), that path would hit the #445 class of cross-assignment again.
Documented as an accepted boundary in extract-ts-types.test.ts ('array/nested destructuring falls through to the bare key'). Filing so the comment can link a tracked follow-up.
Follow-up from PR #522 (#444).
extractMethodTypes(packages/core/src/scripts/extract-ts-types.ts) attributes a factory-returnedApiNamespaceto its namespace only for a top-level identifier or a shallow object binding pattern. Array/tuple patterns and nested destructuring fall through to the bare-key path:Today this is fail-soft: the schema is still recovered under the bare method name, and generate-spec's #498 fallback resolves it when there is no method-name collision. But if a factory returns a tuple of namespaces with a colliding method name (e.g.
const [a, b] = factory()where both exposecreate), that path would hit the #445 class of cross-assignment again.Documented as an accepted boundary in
extract-ts-types.test.ts('array/nested destructuring falls through to the bare key'). Filing so the comment can link a tracked follow-up.