Skip to content

Refactor (packages/codemode/src/openapi/runtime.ts:155): Function with high complexity (count = 44): applyCredentials - #70

Open
emre0gencer wants to merge 3 commits into
CMU-313:mainfrom
emre0gencer:refactor-apply-credentials
Open

Refactor (packages/codemode/src/openapi/runtime.ts:155): Function with high complexity (count = 44): applyCredentials#70
emre0gencer wants to merge 3 commits into
CMU-313:mainfrom
emre0gencer:refactor-apply-credentials

Conversation

@emre0gencer

@emre0gencer emre0gencer commented Sep 6, 2026

Copy link
Copy Markdown

P1B: Starter Task: Refactoring PR

Use this pull request template to briefly answer the questions below in one to two sentences each.
Feel free to delete this text at the top after filling out the template.

1. Issue

Link to the associated GitHub issue: #69

What do you think this file does?
runtime.ts implements the runtime portion of the package's OpenAPI support. It takes the generated operation plan and user input and turns them into HTTP requests by resolving authentication, constructing URLs and parameters, serializing request data, executing the request, and decoding the response.

What is the scope of your refactoring within that file?
My refactoring is limited to applyCredentials and the credential-handling logic used by that function. I reorganized the credential-specific branching into smaller, more focused logic while preserving the existing behavior for bearer, basic, header, and API-key credentials, as well as duplicate-credential and unsupported-authentication error handling.

Which Qlty-reported issue did you address?
packages/codemode/src/openapi/runtime.ts:155 — Function with high complexity (count = 44): applyCredentials.

2. Refactoring

How did the specific issue you chose impact the codebase's maintainability?
applyCredentials previously combined iteration, credential-type dispatch, carrier selection, normalization, validation, duplicate detection, and error handling inside one function. The large number of conditional paths made the function harder to reason about and increased the risk that modifying one authentication type could unintentionally affect another.

What changes did you make to resolve the issue?
I decomposed the credential-processing logic so that applyCredentials has less responsibility and fewer decision points. Credential-type-specific handling is separated from the overall iteration/collection flow, while the existing header/query accumulation and duplicate protection continue to provide a single consistent path for applying credentials. Otherwise, the refactor preserves the observable authentication behavior of the original implementation.

How do your changes improve maintainability? Did you consider alternatives?
The refactoring separates distinct responsibilities and reduces the amount of branching concentrated in applyCredentials, making each authentication path easier to understand, test, and modify independently. I considered reducing complexity through cosmetic rewrites of the existing conditional chain, but that would primarily move syntax around without improving separation of responsibilities. Breaking the credential-handling decisions into focused logic provides a more meaningful maintainability improvement while keeping the refactor narrowly scoped to the Qlty finding.

3. Validation

How did you validate that the change is correct?
I added targeted authentication tests to packages/codemode/test/openapi.test.ts and ran the complete packages/codemode test suite locally. I also ran the repository linter, generated a Bun coverage report, re-ran Qlty against runtime.ts, and verified the tests covering the change through CI.

The authentication tests are sufficient evidence for this refactor because they execute the changed code through the package's normal public OpenAPI path rather than testing an artificial exported helper. A test constructs an OpenAPI security configuration, resolves credentials, executes the generated tool, and then observes the resulting HTTP request or returned ToolError. That execution passes through resolveAuth and the refactored applyCredentials, so assertions on the final headers, query parameters, and authentication failures directly verify the behavior that the refactor could have affected.

The tests specifically exercise the credential-handling behavior touched by the refactor, including successful credential application and relevant validation/error paths. The existing OpenAPI tests also provide regression coverage for the surrounding request-generation behavior, while running the full codemode package suite checks that the refactoring did not break other functionality in the package.

Qtly before:
Image

Qtly after (applyCredentials gone):
Image

Bun test:
Image

Image

Bun Lint (main):

Image

Bun Lint (refactor-apply-credentials):

Image

CI tests:
Ekran görüntüsü 2026-09-06 003216

@emre0gencer emre0gencer changed the title Refactor apply credentials Refactor (packages/codemode/src/openapi/runtime.ts:155): Function with high complexity (count = 44): applyCredentials Sep 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant