feat: Add environment role support

[csrbarber]

Description

• Adds PATCH request support
• Adds Environment Role support

Documentation

Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.

[X] Yes

If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.

[linear]

ENT-4798 workos-node

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds comprehensive support for Environment Roles in the Authorization module, along with PATCH HTTP method support across the SDK.

Key Changes:

• Added PATCH request support to HttpClient and FetchHttpClient with proper retry logic and content-type handling
• Introduced new Authorization module with full CRUD operations for environment roles
• Implemented six environment role methods: createEnvironmentRole, listEnvironmentRoles, getEnvironmentRole, updateEnvironmentRole, setEnvironmentRolePermissions, and addEnvironmentRolePermission
• Added proper TypeScript interfaces with snake_case to camelCase conversion for API responses
• Included comprehensive test coverage with 239 lines of tests covering all operations
• Exported authorization interfaces in main SDK entry points

Implementation Quality:

• Follows existing SDK patterns consistently (POST/PUT/GET structure mirrored for PATCH)
• Proper error handling and API key validation
• Serialization/deserialization layer correctly converts between API and SDK formats
• Tests verify request bodies, URLs, and response transformations

Security & Compliance:

• No violations of custom rules (no SQL concatenation, CORS wildcards, sensitive logging, or TLS disabling)
• PATCH method correctly implements idempotency key support
• API key requirement checks properly enforced

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The implementation follows established patterns consistently, includes comprehensive test coverage, and introduces no security concerns. All changes are additive with no breaking modifications to existing functionality.
• No files require special attention

Important Files Changed

Filename	Overview
src/common/net/http-client.ts	Added abstract patch method signature to support PATCH HTTP requests
src/common/net/fetch-client.ts	Implemented patch method with retry logic and proper content-type handling
src/workos.ts	Added patch method and authorization module instance following existing patterns
src/authorization/authorization.ts	Implemented environment role CRUD operations with proper serialization/deserialization
src/authorization/authorization.spec.ts	Comprehensive test coverage for all environment role operations

Sequence Diagram

sequenceDiagram
    participant Client
    participant WorkOS
    participant Authorization
    participant FetchHttpClient
    participant API as WorkOS API

    Note over Client,API: Create Environment Role
    Client->>WorkOS: workos.authorization.createEnvironmentRole(options)
    WorkOS->>Authorization: createEnvironmentRole(options)
    Authorization->>Authorization: serializeCreateEnvironmentRoleOptions(options)
    Authorization->>WorkOS: workos.post('/authorization/roles', serialized)
    WorkOS->>WorkOS: requireApiKey()
    WorkOS->>FetchHttpClient: client.post(path, entity, headers)
    FetchHttpClient->>API: POST /authorization/roles
    API-->>FetchHttpClient: 201 EnvironmentRoleResponse
    FetchHttpClient-->>WorkOS: HttpClientResponse
    WorkOS-->>Authorization: { data: EnvironmentRoleResponse }
    Authorization->>Authorization: deserializeEnvironmentRole(data)
    Authorization-->>Client: EnvironmentRole

    Note over Client,API: Update Environment Role (PATCH)
    Client->>WorkOS: workos.authorization.updateEnvironmentRole(slug, options)
    WorkOS->>Authorization: updateEnvironmentRole(slug, options)
    Authorization->>Authorization: serializeUpdateEnvironmentRoleOptions(options)
    Authorization->>WorkOS: workos.patch(`/authorization/roles/${slug}`, serialized)
    WorkOS->>WorkOS: requireApiKey()
    WorkOS->>FetchHttpClient: client.patch(path, entity, headers)
    FetchHttpClient->>API: PATCH /authorization/roles/:slug
    API-->>FetchHttpClient: 200 EnvironmentRoleResponse
    FetchHttpClient-->>WorkOS: HttpClientResponse
    WorkOS-->>Authorization: { data: EnvironmentRoleResponse }
    Authorization->>Authorization: deserializeEnvironmentRole(data)
    Authorization-->>Client: EnvironmentRole

    Note over Client,API: List Environment Roles
    Client->>WorkOS: workos.authorization.listEnvironmentRoles(options)
    WorkOS->>Authorization: listEnvironmentRoles(options)
    Authorization->>WorkOS: workos.get('/authorization/roles', { query: options })
    WorkOS->>WorkOS: requireApiKey()
    WorkOS->>FetchHttpClient: client.get(path, headers)
    FetchHttpClient->>API: GET /authorization/roles
    API-->>FetchHttpClient: 200 EnvironmentRoleListResponse
    FetchHttpClient-->>WorkOS: HttpClientResponse
    WorkOS-->>Authorization: { data: EnvironmentRoleListResponse }
    Authorization->>Authorization: deserializeEnvironmentRole() for each
    Authorization-->>Client: EnvironmentRoleList

Loading

[greptile-apps]

_{5 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[mattgd]

Left one comment for consideration, but looks good otherwise!

[mattgd]

Since these are both string types, it may be clearer to make this an object parameter to prevent parameter confusion. Not sure if you'd want to make changes to the other method signatures to align.

[csrbarber]

Yeah this is a JS style question which I'm not sure about. For POST I figured since organizationId is related to the path and not the object being created it should be a separate argument. Similar to this one, I figured since slug is related to the path and not the object, having them separate here made sense.