refactor: migrates another part of console-api to strict types#1362
refactor: migrates another part of console-api to strict types#1362
Conversation
WalkthroughThis update refactors multiple classes to remove an unnecessary generic parameter, enhances null safety and type correctness across repositories and services, replaces lodash utilities with native JavaScript, and improves error handling by adding explicit types and fallback defaults. Additionally, it broadens TypeScript strict settings to more source directories and adjusts configuration files for stricter type checks. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant API
participant Database
User->>API: Request resource (e.g., user, wallet, stats)
API->>Database: Query with improved null/undefined safety
Database-->>API: Data or undefined/null
API->>API: Apply fallback defaults and type-safe transformations
API-->>User: Response with robust, type-safe data
Suggested reviewers
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm warn config production Use 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (26)
🚧 Files skipped from review as they are similar to previous changes (25)
🧰 Additional context used🧠 Learnings (1)apps/api/src/core/services/config/config.service.ts (1)🪛 Biome (1.9.4)apps/api/src/core/services/config/config.service.ts[error] 9-9: Don't use '{}' as a type. Prefer explicitly define the object shape. '{}' means "any non-nullable value". (lint/complexity/noBannedTypes) 🔇 Additional comments (1)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
apps/api/src/healthz/services/healthz/healthz.service.ts (1)
22-22:⚠️ Potential issueRemove debug log message.
The debug log message
"foooo"should be removed as it provides no meaningful information and appears to be leftover from development.- this.logger.info("foooo");
🧹 Nitpick comments (4)
apps/api/tsconfig.strict.json (1)
8-19: Simplify include patterns for maintainability
Instead of enumerating each folder, you can collapse this into a single glob. This reduces upkeep when adding new directories:"include": [ - "src/utils/**/*.ts", - "src/verify-rsa-jwt-cloudflare-worker-main/**/*.ts", - "src/types/**/*.ts", - "src/lib/**/*.ts", - "src/core/**/*.ts", - "src/db/**/*.ts", - "src/healthz/**/*.ts", - "src/middlewares/**/*.ts", - "src/features/**/*.ts", - "src/chain/**/*.ts", - "src/notifications/**/*.ts", - "src/services/**/*.ts" + "src/**/*.ts" ]apps/api/src/billing/repositories/checkout-session/checkout-session.repository.ts (1)
41-41: Consider using more specific error typing instead ofany.While explicitly typing the catch parameter addresses TypeScript strict mode requirements, using
anybypasses type safety. Consider using a more specific approach:- } catch (error: any) { + } catch (error: unknown) { + const errorMessage = error instanceof Error ? error.message : String(error); - if (error.message === "Session is still active") { + if (errorMessage === "Session is still active") {This maintains type safety while properly handling the error message access.
apps/api/src/core/services/tracing/tracing.service.ts (1)
69-69: UseErrortype instead ofanyfor better type safety.Both catch blocks expect error objects with a
messageproperty and usespan.recordException(error). TheErrortype is more appropriate here:- } catch (error: any) { + } catch (error: unknown) { + const err = error instanceof Error ? error : new Error(String(error)); span.setStatus({ code: SpanStatusCode.ERROR, - message: error.message + message: err.message }); - span.recordException(error); + span.recordException(err); span.end(); - throw error; + throw err; }This ensures proper error handling while maintaining type safety.
Also applies to: 172-172
apps/api/src/services/db/userDataService.ts (1)
120-120: Consider using Sequelize error types for better type safety.Both catch blocks handle Sequelize-specific errors. Consider using more specific error types:
- } catch (error: any) { - if (error.name !== "SequelizeUniqueConstraintError") { + } catch (error: unknown) { + if (error instanceof Error && error.name !== "SequelizeUniqueConstraintError") { throw error; }For the second catch block:
- } catch (error: any) { - if (!error.message.includes("user_wallets_user_id_unique")) { + } catch (error: unknown) { + const errorMessage = error instanceof Error ? error.message : String(error); + if (!errorMessage.includes("user_wallets_user_id_unique")) { throw error; }This maintains type safety while properly handling Sequelize errors.
Also applies to: 192-192
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (25)
apps/api/src/auth/services/auth-config/auth-config.service.ts(1 hunks)apps/api/src/billing/repositories/checkout-session/checkout-session.repository.ts(1 hunks)apps/api/src/billing/repositories/user-wallet/user-wallet.repository.ts(3 hunks)apps/api/src/caching/helpers.ts(1 hunks)apps/api/src/chain/services/chain-config/chain-config.service.ts(1 hunks)apps/api/src/core/repositories/base.repository.ts(3 hunks)apps/api/src/core/services/config/config.service.ts(1 hunks)apps/api/src/core/services/core-config/core-config.service.ts(1 hunks)apps/api/src/core/services/error/error.service.ts(1 hunks)apps/api/src/core/services/open-api-hono-handler/open-api-hono-handler.ts(2 hunks)apps/api/src/core/services/tracing/tracing.service.ts(2 hunks)apps/api/src/healthz/services/healthz/healthz.service.ts(1 hunks)apps/api/src/lib/drizzle-ability/drizzle-ability.ts(1 hunks)apps/api/src/services/db/blocksService.ts(4 hunks)apps/api/src/services/db/deploymentService.ts(3 hunks)apps/api/src/services/db/networkRevenueService.ts(2 hunks)apps/api/src/services/db/providerStatusService.ts(1 hunks)apps/api/src/services/db/statsService.ts(7 hunks)apps/api/src/services/db/transactionsService.ts(4 hunks)apps/api/src/services/db/userDataService.ts(3 hunks)apps/api/src/services/external/apiNodeService.ts(5 hunks)apps/api/src/services/external/templateReposService.ts(1 hunks)apps/api/src/services/external/templatesCollector.ts(8 hunks)apps/api/src/user/repositories/user/user.repository.ts(2 hunks)apps/api/tsconfig.strict.json(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (11)
apps/api/src/billing/repositories/checkout-session/checkout-session.repository.ts (1)
packages/logging/src/servicies/logger/logger.service.ts (1)
error(107-109)
apps/api/src/core/services/open-api-hono-handler/open-api-hono-handler.ts (1)
apps/api/src/core/types/app-context.ts (1)
AppContext(6-6)
apps/api/src/services/db/providerStatusService.ts (1)
apps/indexer/drizzle/schema.ts (1)
provider(205-237)
apps/api/src/chain/services/chain-config/chain-config.service.ts (2)
apps/api/src/core/services/config/config.service.ts (1)
ConfigService(9-22)apps/api/src/chain/config/env.config.ts (1)
envSchema(3-5)
apps/api/src/auth/services/auth-config/auth-config.service.ts (2)
apps/api/src/core/services/config/config.service.ts (1)
ConfigService(9-22)apps/api/src/auth/config/env.config.ts (1)
envSchema(3-12)
apps/api/src/services/external/templateReposService.ts (2)
apps/api/src/services/external/templatesCollector.ts (2)
FinalCategory(28-28)getTemplateGallery(102-130)apps/api/src/caching/helpers.ts (2)
cacheResponse(40-74)cacheKeys(76-96)
apps/api/src/services/db/blocksService.ts (1)
apps/indexer/drizzle/schema.ts (1)
message(521-567)
apps/api/src/core/services/error/error.service.ts (1)
packages/logging/src/servicies/logger/logger.service.ts (1)
error(107-109)
apps/api/src/services/db/networkRevenueService.ts (1)
apps/indexer/drizzle/schema.ts (1)
day(92-108)
apps/api/src/services/external/apiNodeService.ts (2)
apps/indexer/drizzle/schema.ts (2)
validator(486-513)provider(205-237)apps/deploy-web/src/utils/apiUtils.ts (3)
delegations(54-56)rewards(48-50)redelegations(51-53)
apps/api/src/services/external/templatesCollector.ts (1)
apps/api/src/utils/templateReposLogos.ts (1)
getLogoFromPath(1-3)
🪛 Biome (1.9.4)
apps/api/src/core/services/config/config.service.ts
[error] 9-9: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: test-api-build
- GitHub Check: validate-api
🔇 Additional comments (63)
apps/api/tsconfig.strict.json (2)
8-19: Broadened strict type-checking scope approved
Including all key subdirectories undersrc/ensures that strict mode is enforced uniformly across the entire API codebase.
8-19:Details
❓ Verification inconclusive
Verify no missing or unintended files
Run a full type-check to surface any gaps or over-inclusions:Ensure test specs or generated artifacts are intentionally included or excluded by your patterns.
🏁 Script executed:
npx tsc --noEmit -p apps/api/tsconfig.strict.jsonLength of output: 678
TypeScript compiler not found – please install and re-run type-check
I attempted to validate yourincludeglobs by running:npx tsc --noEmit -p apps/api/tsconfig.strict.jsonbut npm tried to fetch
tsc@2.0.4instead of using your project’s compiler.
- Add TypeScript to your dev dependencies:
npm install --save-dev typescript- Re-run the type-check:
npx tsc --noEmit -p apps/api/tsconfig.strict.json- Confirm that only intended source files are covered (no test specs or generated artifacts).
Key location to review:
- apps/api/tsconfig.strict.json (lines 8–19 – your
"include"patterns)apps/api/src/healthz/services/healthz/healthz.service.ts (1)
49-50: Excellent defensive programming improvement!The refactoring improves both readability and robustness:
- Better readability: Storing the connection result in a variable makes the logic clearer
- Defensive programming: Adding the
!this.dbFailedAtcheck provides a safety net in case the failure timestamp wasn't properly setThis change aligns well with the PR's objective of improving type safety and null/undefined handling throughout the codebase.
apps/api/src/core/services/config/config.service.ts (1)
16-16:Details
✅ Verification successful
Review the type assertion for potential type safety concerns.
The type assertion
as C & z.infer<E>bypasses TypeScript's type checking and could hide type safety issues. Consider whether the spread operation and optional chaining provide sufficient type safety guarantees, or if additional runtime validation is needed.Verify that the type assertion is necessary and doesn't mask underlying type incompatibilities:
🏁 Script executed:
#!/bin/bash # Search for other type assertions in config-related files to understand the pattern rg -A 3 -B 3 " as " --type ts | grep -E "(config|Config)" -A 3 -B 3Length of output: 65606
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "=== ConfigService implementation (apps/api/src/core/services/config/config.service.ts) ===" sed -n '1,200p' apps/api/src/core/services/config/config.service.ts || true echo echo "=== Instances of ConfigService being created ===" rg -n "new ConfigService" -n apps/api/src || trueLength of output: 1118
Type assertion in ConfigService is intentional and necessary
TypeScript currently can’t infer the precise intersection type resulting from spreadingoptions.configand the result ofenvSchema.parse. Theas C & z.infer<E>assertion restores your intended static type, and the call toenvSchema.parse()ensures runtime validation of all environment‐derived values. If you need runtime checks foroptions.config, you can layer a Zod schema around it or validate it before passing it in, but no changes are required here.apps/api/src/chain/services/chain-config/chain-config.service.ts (1)
7-7: LGTM! Clean simplification of generic parameters.The removal of the second generic parameter
unknownis a good simplification that leverages the new default parameter in the baseConfigServiceclass. This maintains type safety while reducing boilerplate.apps/api/src/auth/services/auth-config/auth-config.service.ts (1)
7-7: LGTM! Consistent with the refactoring pattern.The simplification matches the pattern established in other config services, correctly utilizing the new default generic parameter while maintaining type safety.
apps/api/src/core/services/core-config/core-config.service.ts (1)
7-7: LGTM! Completes the consistent refactoring pattern.This change aligns with the other config service simplifications, correctly leveraging the default generic parameter introduced in the base
ConfigServiceclass.apps/api/src/caching/helpers.ts (1)
46-47: LGTM! Good refactoring for clarity.The logic simplification effectively combines the null check and expiration check into a single, more readable condition. The behavior remains unchanged while improving code clarity.
apps/api/src/services/db/userDataService.ts (1)
93-93: LGTM! Good explicit typing.Adding explicit
UserSetting | nulltyping improves code clarity and ensures proper null handling throughout the function.apps/api/src/core/services/error/error.service.ts (1)
8-8: Excellent type safety improvement!The updated return type
Promise<T | undefined>accurately reflects that the method returnsundefinedwhen an error is caught and handled. This makes the type signature consistent with the actual runtime behavior.apps/api/src/core/services/open-api-hono-handler/open-api-hono-handler.ts (1)
7-7: Import addition looks good.Adding
AppContextto the imports is appropriate for the type casting used below.apps/api/src/services/external/templatesCollector.ts (9)
13-13: Good type safety improvement for task tracking.Allowing
nullvalues in thegeneratingTasksdictionary accurately reflects the cleanup logic where tasks are set tonullafter completion (line 79).
15-15: Type expansion for GitHub rate limit tracking.Adding
undefinedto the type correctly handles cases where the rate limit header might not be present in API responses.
159-159: Improved API parameter handling.Changing from
nullto empty string""is more appropriate for the GitHub API path parameter, which expects a string value for the repository root.
361-361: Explicit type casting improves clarity.Adding the type assertion
as GithubDirectoryItem[]makes the expected type explicit and improves code readability.
375-375: Safe null handling with optional chaining.The optional chaining
readme?.toLowerCase()prevents potential runtime errors whenreadmeis null or undefined.
389-390: Consistent fallback handling for template properties.Adding fallback empty strings for
logoUrlandsummaryensures these required properties are always strings, preventing potential undefined values from causing issues downstream.Also applies to: 407-407, 411-411, 478-479, 497-497
402-403: Improved boolean and optional property handling.The explicit boolean conversion
!!deployand conditional assignmentguide || undefinedprovide clearer intent and consistent type handling.Also applies to: 486-487
419-419: Explicit error typing for better access.Adding
err: anyenables safe access to error properties likeerr.messagewhile maintaining TypeScript compatibility.Also applies to: 505-505
425-425: Clear filtering with explicit truthiness check.Using
filter(x => !!x)is more explicit than relying on implicit truthiness, making the filtering intent clearer.Also applies to: 511-511
apps/api/src/services/external/templateReposService.ts (1)
6-20: Excellent refactoring for better error handling and clarity!The changes provide several improvements:
- Early validation: GitHub PAT is checked upfront with a clear error message
- Explicit dependencies: The PAT is passed as a parameter rather than accessed via closure
- Better error locality: Failures happen at the function entry point rather than deep in the async operation
This aligns well with the broader type safety improvements across the codebase.
apps/api/src/lib/drizzle-ability/drizzle-ability.ts (1)
44-46: LGTM! Good type safety improvement.The widened parameter type to
SQL | undefinedallows for more flexible usage while maintaining correct handling of undefined values. The implementation correctly returns the originalwhereclause whenabilityClauseis falsy.apps/api/src/services/db/deploymentService.ts (2)
57-59: LGTM! Excellent null safety improvement.The optional chaining (
?.) prevents potential runtime errors whenbidIdororderproperties are undefined or null, which is crucial when dealing with decoded protobuf messages that may have optional fields.
78-79: LGTM! Clean refactor of operator assignment.The dynamic operator assignment (
Op.isfor "active",Op.nefor "closed") standardizes the Sequelize filter syntax and improves code readability while maintaining the same functionality.Also applies to: 93-94
apps/api/src/services/db/providerStatusService.ts (1)
28-46: LGTM! Essential numeric safety improvements.The
|| 0fallback defaults prevent NaN or undefined accumulation errors when provider snapshot resource fields are missing or falsy. This defensive coding pattern ensures robust numeric calculations and aligns perfectly with the strict types migration objective.apps/api/src/services/db/networkRevenueService.ts (3)
95-131: LGTM! Consistent numeric safety pattern.The
|| 0fallback defaults for revenue fields prevent undefined/null accumulation errors during the revenue calculations. This defensive coding approach ensures reliable numeric operations throughout the revenue aggregation logic.
198-200: LGTM! Proper null handling for database fields.The fallback defaults for
totalUAktSpent,totalUUsdcSpent, andaktPriceprevent runtime errors when these optional database fields are null or undefined, ensuring safe numeric operations downstream.
203-203: LGTM! Improved type safety with explicit typing.The explicit type annotation for the
relativeStatsarray in the reducer enhances type safety and makes the return type clear, which aligns well with the strict types migration objective.apps/api/src/services/db/blocksService.ts (3)
72-76: Excellent defensive programming improvements!The addition of null safety checks for
tx.messagesandmessage.amountprevents potential runtime errors. The fallback to an empty array and "0" string ensures safe iteration and parsing.
95-97: Good explicit error handling for missing data.Adding an explicit error when the earlier block is not found prevents silent failures and provides clear feedback about calculation issues.
113-113: Consistent null safety for latest block checks.Both functions now properly handle the case where no blocks are found, providing clear error messages instead of proceeding with undefined data.
Also applies to: 132-132
apps/api/src/services/db/transactionsService.ts (4)
38-42: Consistent null safety for messages array and amount parsing.Good defensive programming by safely handling potentially null
tx.messagesand providing a "0" fallback for amount parsing.
83-84: Improved null handling for address references and error logging.The null safety for
tx.addressReferencesand explicit null handling for the error field improve robustness and clarity.
93-93: Explicit null fallback for relatedDeploymentId.Good practice to explicitly handle potentially missing
relatedDeploymentIdwith a null fallback.
143-144: Comprehensive null safety for address references throughout the function.All instances of
tx.addressReferencesaccess are now protected with null safety checks, ensuring consistent defensive programming.Also applies to: 148-148
apps/api/src/billing/repositories/user-wallet/user-wallet.repository.ts (4)
51-53: Good migration from lodash to native JavaScript.Using array destructuring instead of lodash
first()is more idiomatic and type-safe.
67-72: Excellent explicit null safety checks.Adding early returns for falsy
userIdand missinguserWalletimproves type safety and prevents potential runtime errors.
88-94: Improved object transformation without lodash.Using object spreading instead of
omitis more explicit and eliminates the lodash dependency while maintaining the same functionality.
76-76:Details
✅ Verification successful
Verify the necessity of explicit type casting.
The explicit casting to
stringandstring[]suggests potential type system gaps. Consider if the method signature could be made more type-safe to avoid manual casting.
🏁 Script executed:
#!/bin/bash # Check if there are type definitions that could eliminate the need for casting ast-grep --pattern 'findByUserId($PARAM) { $$$ }'Length of output: 53
🏁 Script executed:
#!/bin/bash # Locate the findByUserId method and its signature to verify parameter types rg -n "findByUserId" apps/api/src/billing/repositories/user-wallet/user-wallet.repository.ts rg -A3 "findByUserId" apps/api/src/billing/repositories/user-wallet/user-wallet.repository.tsLength of output: 623
🏁 Script executed:
#!/bin/bash # Find type/interface definition for UserWalletOutput to inspect the userId property type rg -nE "export (type|interface) UserWalletOutput" . rg -A5E "export (type|interface) UserWalletOutput" .Length of output: 267
No change needed: explicit type assertions are required
TypeScript’s built-in Array.isArray() guard narrowsuserIdtoany[], notstring[], so the casts tostring/string[]are necessary to satisfy the signatures ofeqandinArray. If you’d like to avoid these assertions, you could introduce a custom type-guard (x is string[]), but the current implementation is both correct and clear.apps/api/src/services/external/apiNodeService.ts (4)
134-138: Comprehensive optional chaining for validator data access.Excellent defensive programming by using optional chaining for all validator property access. This prevents runtime errors when validator objects might be undefined.
Also applies to: 154-158, 174-178, 180-184
146-146: Safe array access with proper fallbacks.Good practice using optional chaining combined with fallback values for array
find()operations and amount parsing.Also applies to: 167-167
325-329: Robust handling of proposal tally data.The optional chaining for
final_tally_resultproperties with "0" fallbacks ensures safe numeric parsing even when tally data is missing.
428-444: Thorough defensive programming for deployment lease data.The comprehensive use of optional chaining for provider properties and deeply nested group/resource data is excellent. The fallback values (0) ensure mathematical operations remain safe even when data is missing.
apps/api/src/core/repositories/base.repository.ts (8)
52-54: LGTM: Improved parameter type safetyThe parameter type change from
SQLtoSQL | undefinedbetter reflects the actual usage and improves type safety by explicitly handling undefined values.
58-63: LGTM: Enhanced type safety and native JavaScript usageThe explicit
Promise<Output>return type and replacement of lodashfirst()with array destructuring improves type clarity and removes external dependencies. The implementation correctly handles the array destructuring pattern.
65-67: LGTM: Accurate return type reflecting potential undefined resultAdding
undefinedto the return type accurately represents thatfindByIdmay not find a matching record, improving type safety for consumers of this method.
69-75: LGTM: Consistent null safety patternThe return type update and method implementation maintain consistency with other find methods while properly handling potential undefined results.
77-87: LGTM: Comprehensive type improvements with proper null handlingThe explicit typing and null checking (
if (!items) return undefined;) ensure robust handling of transaction scenarios where the transaction manager might not be available. The array indexingitems[0]is safe after the null check.
157-159: LGTM: Consistent array destructuring patternThe replacement of lodash
first()with array destructuring maintains consistency with other method updates in this file.
177-179: LGTM: Consistent pattern applicationSame beneficial change as other methods - replacing lodash with native JavaScript array destructuring.
186-193: LGTM: Improved null safety and explicit handlingThe early return for falsy queries and explicit typing enhance the method's robustness. The parameter type change to include
undefinedaligns with the actual usage patterns.apps/api/src/services/db/statsService.ts (7)
18-18: LGTM: Excellent utility function for null safetyThe
numberOrZeroutility function provides a clean, type-safe way to handle potentially undefined or null numeric values. The type guard approach is more robust than simple truthy checking.
27-29: LGTM: Proper error handling for data dependencyAdding an explicit error throw when no block stats are found prevents silent failures and makes the data dependency requirement clear. This is a good defensive programming practice.
53-80: LGTM: Comprehensive null safety improvementsThe systematic application of
numberOrZero()and optional chaining (?.) throughout the calculations ensures robust handling of potentially missing data. This prevents runtime errors from undefined/null arithmetic operations.
125-157: LGTM: Consistent null safety pattern in getter functionsThe application of
numberOrZero()to all numeric field accesses in the getter functions ensures consistent behavior across different data types. The variable type change from nullable to non-nullable reflects the actual usage after proper initialization.
174-174: LGTM: Safe property access with non-null assertionThe non-null assertion (
!) is appropriate here since the query includesrequired: truefor the lastBlock association, guaranteeing its presence.
183-183: LGTM: Explicit type annotation for reducerAdding explicit typing to the reducer accumulator improves code clarity and helps TypeScript provide better type checking.
198-199: LGTM: Final safety layer for dashboard dataApplying
numberOrZero()to the dashboard data extraction provides a final safety layer, ensuring the returned values are always numbers even if the dashboard data has unexpected structure.apps/api/src/user/repositories/user/user.repository.ts (5)
28-31: LGTM: Enhanced type safety and native JavaScript usageThe explicit typing of input parameter and return type, combined with array destructuring instead of lodash
first(), improves type safety and reduces external dependencies. The implementation correctly handles the repository pattern.
33-35: LGTM: Accurate return type for find operationAdding
undefinedto the return type correctly represents thatfindByIdmay not find a matching user, improving type safety for method consumers.
37-39: LGTM: Type safety improvements with appropriate assertionThe return type update improves type safety. The non-null assertion on
userId!is reasonable since this method would typically be called with a valid userId parameter.
45-45: LGTM: Explicit return type annotationAdding the explicit
Promise<void>return type improves method signature clarity and type safety.
72-72: LGTM: Modern array method usageReplacing lodash
last()with the nativeArray.prototype.at(-1)method removes external dependencies while maintaining the same functionality. The optional chaining ensures safe access.
apps/api/src/core/services/open-api-hono-handler/open-api-hono-handler.ts
Show resolved
Hide resolved
stalniy
force-pushed
the
refactor/strict-types-2
branch
2 times, most recently
from
b15caf0 to
12b0b0d
Compare
stalniy
force-pushed
the
refactor/strict-types-2
branch
from
12b0b0d to
8b1c910
Compare
Pull request was closed
stalniy
force-pushed
the
refactor/strict-types-2
branch
from
8b1c910 to
131dbe0
Compare
stalniy
force-pushed
the
refactor/strict-types-2
branch
from
131dbe0 to
b25c64b
Compare
stalniy
force-pushed
the
refactor/strict-types-2
branch
from
b25c64b to
2e15e68
Compare
Codecov ReportAttention: Patch coverage is
❌ Your patch status has failed because the patch coverage (44.02%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #1362 +/- ##
==========================================
+ Coverage 35.63% 35.70% +0.07%
==========================================
Files 808 808
Lines 19608 19670 +62
Branches 3619 3717 +98
==========================================
+ Hits 6988 7024 +36
- Misses 11889 11912 +23
- Partials 731 734 +3
*This pull request uses carry forward flags. Click here to find out more.
🚀 New features to boost your workflow:
|
2 participants
Summary by CodeRabbit
at()for safer, more modern array handling.Promise<Output | undefined>where applicable.