fix(types): add extends to role and resource-role types (PER-16500)

[Kyzgor]

Summary

• Adds the optional extends?: string[] field (the roles this role inherits permissions from) to RoleCreate, RoleRead, RoleUpdate, ResourceRoleCreate, ResourceRoleRead and ResourceRoleUpdate, matching the public API spec.
• Adds unit tests. They pin the type of extends on all six public method signatures and check that roles and resourceRoles create, update and get pass the field through unchanged.
• This is a stopgap until the OpenAPI client is regenerated. The edits follow the generator's output format, so a regeneration replaces them cleanly.

Linear

• Part of PER-16500: Node SDK: restore OpenAPI client regeneration (generator 6.2.1 can't read the 3.1 spec) and ship the missing role extends types

Details

Types

src/openapi/ was last regenerated in March 2024, so the six role models have no extends field, although the API accepts and returns it. Each model now declares the property with the spec's description, in the generator's JSDoc style.

Checked against https://api.permit.io/v2/openapi.json (OpenAPI 3.1.0, fetched 2026-09-29): extends is an optional, non-nullable array<string> in all six schemas.

Tests (src/tests/unit/role-extends.spec.ts, run by yarn test:unit)

• Type contracts. For the parameter and return types of roles.create/get/update and resourceRoles.create/get/update, Pick<T, 'extends'> must equal { extends?: Array<string> } exactly. This rejects any, null, non-array values and a required field. build:types compiles these assertions before AVA runs.
• Runtime. A stub axios adapter records each request. For multiple inherited roles, an empty list and an omitted field, create and update send extends unchanged and get returns it unchanged (6 AVA cases).
• Mutation check. The new tests catch 67 of 67 type mutations and 6 of 6 runtime mutations (dropping extends in a wrapper). The previous test caught 18 of 67 and 0 of 6.

Testing

• yarn build: passes
• yarn lint: 0 errors (7 existing warnings in untouched test files)
• yarn test:unit: 54 passed
• yarn test:module-imports: 9 passed

Notes

• Release note: callers that pass extends: null should omit the field instead.
• Follow-ups under PER-16500, not in this PR:
  • export the resource-roles API from src/api/index.ts;
  • type the embedded roles maps;
  • add RoleCreateBulk;
  • remove the stale role-block.ts.
• role-extends.spec.ts uses AVA, like the rest of main. When the Vitest migration (test: migrate AVA→Vitest with event-based waits (stacked on #131) #132, folded into permitio 3.0.0: refactor SDK APIs, tests, and release validation #134) lands, it needs porting, and its type assertions must stay compiled.

Original change by @Kyzgor; the test commits were added by the maintainers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PSoip6dghQ62bLQ6GBMwTA

[zeevmoney]

The extends addition itself is correct — it matches the backend exactly (extends: Optional[list[str]] on the shared _Editable base, inherited by RoleCreate/Read/Update; permit-backend .../schemas/schema_role.py:56-60). The blockers are scope and method, not the field.

[Copilot]

Pull request overview

This PR aims to align the SDK’s generated Role TypeScript interfaces with the Permit.io OpenAPI spec by adding the missing extends?: Array<string> field, enabling role inheritance in create/update flows and typed access when reading roles. It also includes runtime dependency upgrades and a logging implementation change to support newer pino/pino-pretty behavior.

Changes:

• Add extends?: Array<string> to RoleRead, RoleCreate, and RoleUpdate interfaces.
• Update logger initialization to use pino.transport with pino-pretty when config.log.json is false.
• Bump multiple runtime dependencies (axios/lodash/path-to-regexp/pino/pino-pretty) and regenerate yarn.lock accordingly.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
yarn.lock	Lockfile updates reflecting dependency upgrades and transitive changes.
package.json	Updates runtime dependency versions (axios/lodash/path-to-regexp/pino/pino-pretty).
src/logger.ts	Reworks logger creation to use pino-pretty transport instead of deprecated prettyPrint.
src/openapi/types/role-create.ts	Adds extends?: Array<string> to role creation type.
src/openapi/types/role-read.ts	Adds extends?: Array<string> to role read type.
src/openapi/types/role-update.ts	Adds extends?: Array<string> to role update type.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Kyzgor]

Thanks for the review. Agreed on scope and the missing test, both fixed below. One note on the regenerate suggestion.

Scope: dropped the logger.ts rewrite and the dependency/lockfile changes. The PR is now only the extends type addition plus a test.

Test: added src/tests/unit/role-extends.spec.ts, which pins extends on all six types (create/read/update for Role and ResourceRole). It fails to compile if any of the additions is reverted.

On regenerating instead of hand-editing: I tried that first, and yarn generate-openapi-client is broken right now. The pinned generator (6.2.1) can't read the live spec, which is now OpenAPI 3.1.0, so it regenerates an all-any client (247 of 319 type files lose their types) and exits 0. Running it today would replace the whole typed client with any, not just add extends. I wrote it up with a reproduction and a few options in #130. Until that's sorted, the hand-add matches what a working generator emits (same doc comment, same position between attributes and granted_to), so it folds into the next clean regen as a no-op. This follows existing practice in the repo, e.g. be9b59a (created_at/updated_at on userRead) and c502f4e (a field on derived-role-rule-create), both manual edits to src/openapi/types/*.ts.

I also extended it to the ResourceRole types (create/read/update), which carry extends in the spec and had the same gap.

[zeevmoney]

Approved. The earlier scope and regeneration points are addressed. Verified with main plus #125 and #135: build, lint and unit tests pass, and CI is green.