feat: more supported equipment types #867

Sainan · 2025-01-24T15:57:40-08:00

AMelonInsideLemon commented

2025-01-24 15:57:40 -08:00

(Migrated from github.com)

Closes #832

coderabbitai[bot] commented

2025-01-24 15:57:46 -08:00

(Migrated from github.com)

Walkthrough

The pull request introduces significant changes to the inventory and equipment handling system across multiple files. The modifications primarily focus on restructuring the inventory model to support more dynamic and flexible equipment types. Key changes include the removal of specific equipment type references and replacing them with a more generic, key-based approach using equipmentKeys and TEquipmentKey.

The changes affect several core files such as inventoryModel.ts, importService.ts, missionInventoryUpdateService.ts, and various type definition files. The implementation introduces new interfaces for equipment details, adds support for new equipment types like Kubrow pets, and modifies how equipment experience and configurations are handled. The overall approach moves towards a more generalized and extensible system for managing different types of equipment in the inventory.

Assessment against linked issues

Objective	Addressed	Explanation
Add Necramech to `equipmentKeys`	✅
Handle Necramech XP in mission inventory update	✅
Support dynamic equipment type handling	✅

✨ Finishing Touches

📝 Generate Docstrings (Beta)

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Generate unit testing code for this file.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai generate unit testing code for this file.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and generate unit testing code.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

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)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

## Walkthrough The pull request introduces significant changes to the inventory and equipment handling system across multiple files. The modifications primarily focus on restructuring the inventory model to support more dynamic and flexible equipment types. Key changes include the removal of specific equipment type references and replacing them with a more generic, key-based approach using `equipmentKeys` and `TEquipmentKey`. The changes affect several core files such as `inventoryModel.ts`, `importService.ts`, `missionInventoryUpdateService.ts`, and various type definition files. The implementation introduces new interfaces for equipment details, adds support for new equipment types like Kubrow pets, and modifies how equipment experience and configurations are handled. The overall approach moves towards a more generalized and extensible system for managing different types of equipment in the inventory. ## Assessment against linked issues | Objective | Addressed | Explanation | |---------------------------------------------------|-----------|-------------| | Add Necramech to `equipmentKeys` | ✅ | | | Handle Necramech XP in mission inventory update | ✅ | | | Support dynamic equipment type handling | ✅ | |      <details> <summary>✨ Finishing Touches</summary> - [ ]  📝 Generate Docstrings (Beta) </details>   --- Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? <details> <summary>❤️ Share</summary> - [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai) - [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai) - [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai) - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code) </details> <details> <summary>🪧 Tips</summary> ### Chat There are 3 ways to chat with [CodeRabbit](https://coderabbit.ai): - Review comments: Directly reply to a review comment made by CodeRabbit. Example: - `I pushed a fix in commit <commit_id>, please review it.` - `Generate unit testing code for this file.` - `Open a follow-up GitHub issue for this discussion.` - Files and specific lines of code (under the "Files changed" tab): Tag `@coderabbitai` in a new review comment at the desired location with your query. Examples: - `@coderabbitai generate unit testing code for this file.` - `@coderabbitai modularize this function.` - PR comments: Tag `@coderabbitai` in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples: - `@coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.` - `@coderabbitai read src/utils.ts and generate unit testing code.` - `@coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.` - `@coderabbitai help me debug CodeRabbit configuration file.` 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) - `@coderabbitai pause` to pause the reviews on a PR. - `@coderabbitai resume` to resume the paused reviews. - `@coderabbitai review` to trigger an incremental review. This is useful when automatic reviews are disabled for the repository. - `@coderabbitai full review` to do a full review from scratch and review all the files again. - `@coderabbitai summary` to regenerate the summary of the PR. - `@coderabbitai generate docstrings` to [generate docstrings](https://docs.coderabbit.ai/finishing-touches/docstrings) for this PR. ([Beta](https://docs.coderabbit.ai/early-access#beta)) - `@coderabbitai resolve` resolve all the CodeRabbit review comments. - `@coderabbitai configuration` to show the current CodeRabbit configuration for the repository. - `@coderabbitai help` to get help. ### Other keywords and placeholders - Add `@coderabbitai ignore` anywhere in the PR description to prevent this PR from being reviewed. - Add `@coderabbitai summary` to generate the high-level summary at a specific location in the PR description. - Add `@coderabbitai` anywhere in the PR title to generate the title automatically. ### Documentation and Community - Visit our [Documentation](https://docs.coderabbit.ai) for detailed information on how to use CodeRabbit. - Join our [Discord Community](http://discord.gg/coderabbit) to get help, request features, and share feedback. - Follow us on [X/Twitter](https://twitter.com/coderabbitai) for updates and announcements. </details>

coderabbitai[bot] (Migrated from github.com) reviewed 2025-01-24 16:05:51 -08:00

coderabbitai[bot] (Migrated from github.com) left a comment

Actionable comments posted: 1

🧹 Nitpick comments (8)

src/types/inventoryTypes/inventoryTypes.ts (1)

70-79: Add unit tests for new equipment categories
The new arrays for equipment types (Scoops, Horses, DrifterGuns, etc.) align with the PR objective of introducing more supported equipment. Ensure that these new properties are covered in your test suite for correct behavior and serialization.
src/models/inventoryModels/inventoryModel.ts (3)
734-744: toJSON transform in detalisSchema
Line 736 deletes returnedObject.__v, which can degrade performance. Consider assigning undefined instead to maintain object shape:
- delete returnedObject.__v;
+ returnedObject.__v = undefined;
🧰 Tools

🪛 Biome (1.9.4)

[error] 736-736: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

784-797: toJSON transform for equipment
At lines 787 and 788, the code deletes _id and __v. For better performance, consider:
- delete returnedObject._id;
- delete returnedObject.__v;
+ returnedObject._id = undefined;
+ returnedObject.__v = undefined;
🧰 Tools

🪛 Biome (1.9.4)

[error] 787-787: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 788-788: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

799-799: equipmentFields object
This dynamic record is a concise technique. For stronger type safety, consider building a mapped type keyed by TEquipmentKey to avoid broad any.
src/types/inventoryTypes/commonInventoryTypes.ts (1)
137-141: Consider documenting the purpose of each new property.

While the implementation is correct, adding JSDoc comments for the new properties would improve code maintainability.
+    /** Weapon configuration for crew ships */
     Weapon?: ICrewShipWeapon;
+    /** Customization options for crew ships */
     Customization?: ICrewShipCustomization;
+    /** Railjack image configuration */
     RailjackImage?: IFlavourItem;
+    /** Crew member assignments */
     CrewMembers?: ICrewShipMembersDatabase;
+    /** Kubrow pet-specific details */
     Details?: IKubrowPetDetailsDatabase;
src/services/saveLoadoutService.ts (1)

143-165: LGTM! Improved equipment handling with dynamic keys.

The code has been refactored to use a more maintainable approach:

Uses equipmentKeys for dynamic type checking

Properly handles configuration updates

Includes appropriate error logging

Consider extracting the configuration update logic into a separate function for better modularity and testability.
src/services/importService.ts (1)
50-65: Fix empty array handling and add comments for the workaround.

The empty array filtering is a good fix, but the comment could be more descriptive.
-        /*  fix for
-            "attcol": [],
-            "sigcol": [],
-            "eyecol": [],
-            "facial": [],
-            in data from aleca */
+        /* Remove empty color arrays from configs to prevent issues
+         * This fixes a data inconsistency where empty arrays are sent
+         * for color properties: attcol, sigcol, eyecol, facial
+         * Reference: Issue #832
+         */
src/services/missionInventoryUpdateService.ts (1)
149-153: Consider adding error handling for invalid equipment types.

While the dynamic equipment handling is good, it could benefit from additional error handling.
 if (equipmentKeys.includes(key as TEquipmentKey)) {
+    try {
         addGearExpByCategory(inventory, value as IEquipmentClient[], key as TEquipmentKey);
+    } catch (error) {
+        logger.error(`Failed to update XP for equipment type ${key}:`, error);
+    }
 }

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b72a0d12ef and ac41c6321c.

📒 Files selected for processing (7)

src/models/inventoryModels/inventoryModel.ts (4 hunks)
src/services/importService.ts (3 hunks)
src/services/missionInventoryUpdateService.ts (3 hunks)
src/services/saveLoadoutService.ts (2 hunks)
src/types/inventoryTypes/commonInventoryTypes.ts (3 hunks)
src/types/inventoryTypes/inventoryTypes.ts (4 hunks)
src/types/requestTypes.ts (1 hunks)

🧰 Additional context used

🪛 Biome (1.9.4)

src/models/inventoryModels/inventoryModel.ts

[error] 736-736: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 787-787: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 788-788: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

🔇 Additional comments (33)

src/types/inventoryTypes/inventoryTypes.ts (5)

109-119: Extended equipmentKeys
Including the new equipment type strings in equipmentKeys is consistent with your dynamic approach. Verify that all references to these keys (including UI, services, and test code) are updated accordingly.

189-198: Synced new client equipment definitions
These additional properties in IInventoryClient mirror the expansions in IInventoryDatabase. Confirm that calls referencing them in the client layer are properly handled, especially for newly added equipment categories.

649-649: New IKubrowPetDetailsDatabase interface
This typed interface for Kubrow pet details increases clarity and maintainability. Consider adding a short doc comment explaining standard usage scenarios for future reference.

655-655: Switched HatchDate to a native Date
Using a native Date can simplify server-side date handling. Ensure that any previously stored IMongoDate fields or related code paths are updated to avoid inconsistencies.

662-665: Introduced IKubrowPetDetailsClient
This client-side interface correctly replaces HatchDate with IMongoDate, matching patterns elsewhere in the codebase that return date-like fields to the client. No issues found.

src/models/inventoryModels/inventoryModel.ts (22)

55-60: Updated imports for inventory types
These added imports (including TEquipmentKey and IKubrowPetDetailsClient) align with the extended equipment system. Confirm all references to the new types stay consistent across the codebase.

702-716: New traitsSchema for Kubrow pets
Defining a dedicated schema for pet traits (base color, personality, etc.) provides clarity. If certain fields can be absent, mark them optional to reflect real-world usage.

717-717: Empty line
No changes needed.

718-732: detalisSchema for Kubrow pet details
Fields like Name, IsPuppy, and HasCollar expand pet functionality. The schema naming aligns well with the rest of the code; keep it consistent in references.

733-733: Empty line
No changes needed.

745-776: Enhanced EquipmentSchema
Adding fields like Weapon, Customization, CrewMembers, and Details expands equipment to cover new scenarios (Railjack, Kubrow, etc.). This broadens the schema's utility without obvious issues.

777-777: Empty line
No changes needed.

778-778: Empty line
No changes needed.

779-779: Empty line
No changes needed.

780-782: ItemId virtual property in EquipmentSchema
This virtual property generation is consistent with the rest of your schemas, preserving a consistent client ID format.

783-783: Empty line
No changes needed.

798-798: Empty line
No changes needed.

800-800: Empty line
No changes needed.

801-803: Populating dynamic equipment arrays
Using forEach with equipmentKeys demonstrates a clean approach to constructing the schema.

804-804: Empty line
No changes needed.

805-817: infestedFoundrySchema additions
Properties like LastConsumedSuit and AbilityOverrideUnlockCooldown expand infested foundry functionality. Watch for multi-thread data updates if concurrency is a concern.

818-818: Empty line
No changes needed.

819-819: Empty line
No changes needed.

820-820: Empty line
No changes needed.

821-829: infestedFoundrySchema toJSON transform
Converting AbilityOverrideUnlockCooldown to a Mongo-friendly date is consistent with the code’s date-handling pattern.

862-863: Spread operator for equipment fields
...equipmentFields elegantly injects dynamic equipment arrays into the schema. This fortifies your approach to new gear types.

1181-1181: Extended InventoryDocumentProps
Mapping TEquipmentKey to a Types.DocumentArray<IEquipmentDatabase> ensures the schema can store newly introduced category arrays consistently.

src/types/requestTypes.ts (1)

75-76: Adopting dynamic equipment fields
Removing explicit array properties in favor of a mapped type keyed by TEquipmentKey is more scalable. Confirm any older usage of direct fields has been refactored accordingly.

src/types/inventoryTypes/commonInventoryTypes.ts (2)

3-11: LGTM! Well-organized imports for new equipment types.

The new imports are properly organized and follow TypeScript best practices.

91-100: LGTM! Clean interface extension with optional properties.

The IEquipmentClient interface is properly extended with optional properties for crew members and pet details, maintaining backward compatibility.

src/services/saveLoadoutService.ts (1)

15-15: LGTM! Good use of type imports.

The import of equipmentKeys and TEquipmentKey enables type-safe dynamic equipment handling.

src/services/importService.ts (1)

22-23: LGTM! Proper imports for new types.

The imports for Kubrow pet-related types are properly organized.

src/services/missionInventoryUpdateService.ts (1)

5-5: LGTM! Well-organized imports.

The imports are properly organized and follow TypeScript best practices.

Also applies to: 25-25

**Actionable comments posted: 1** <details> <summary>🧹 Nitpick comments (8)</summary><blockquote> <details> <summary>src/types/inventoryTypes/inventoryTypes.ts (1)</summary><blockquote> `70-79`: **Add unit tests for new equipment categories** The new arrays for equipment types (Scoops, Horses, DrifterGuns, etc.) align with the PR objective of introducing more supported equipment. Ensure that these new properties are covered in your test suite for correct behavior and serialization. </blockquote></details> <details> <summary>src/models/inventoryModels/inventoryModel.ts (3)</summary><blockquote> `734-744`: **toJSON transform in detalisSchema** Line 736 deletes `returnedObject.__v`, which can degrade performance. Consider assigning `undefined` instead to maintain object shape: ```diff - delete returnedObject.__v; + returnedObject.__v = undefined; ``` <details> <summary>🧰 Tools</summary> <details> <summary>🪛 Biome (1.9.4)</summary> [error] 736-736: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> --- `784-797`: **toJSON transform for equipment** At lines 787 and 788, the code deletes `_id` and `__v`. For better performance, consider: ```diff - delete returnedObject._id; - delete returnedObject.__v; + returnedObject._id = undefined; + returnedObject.__v = undefined; ``` <details> <summary>🧰 Tools</summary> <details> <summary>🪛 Biome (1.9.4)</summary> [error] 787-787: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 788-788: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> --- `799-799`: **equipmentFields object** This dynamic record is a concise technique. For stronger type safety, consider building a mapped type keyed by `TEquipmentKey` to avoid broad `any`. </blockquote></details> <details> <summary>src/types/inventoryTypes/commonInventoryTypes.ts (1)</summary><blockquote> `137-141`: **Consider documenting the purpose of each new property.** While the implementation is correct, adding JSDoc comments for the new properties would improve code maintainability. ```diff + /** Weapon configuration for crew ships */ Weapon?: ICrewShipWeapon; + /** Customization options for crew ships */ Customization?: ICrewShipCustomization; + /** Railjack image configuration */ RailjackImage?: IFlavourItem; + /** Crew member assignments */ CrewMembers?: ICrewShipMembersDatabase; + /** Kubrow pet-specific details */ Details?: IKubrowPetDetailsDatabase; ``` </blockquote></details> <details> <summary>src/services/saveLoadoutService.ts (1)</summary><blockquote> `143-165`: **LGTM! Improved equipment handling with dynamic keys.** The code has been refactored to use a more maintainable approach: - Uses equipmentKeys for dynamic type checking - Properly handles configuration updates - Includes appropriate error logging Consider extracting the configuration update logic into a separate function for better modularity and testability. </blockquote></details> <details> <summary>src/services/importService.ts (1)</summary><blockquote> `50-65`: **Fix empty array handling and add comments for the workaround.** The empty array filtering is a good fix, but the comment could be more descriptive. ```diff - /* fix for - "attcol": [], - "sigcol": [], - "eyecol": [], - "facial": [], - in data from aleca */ + /* Remove empty color arrays from configs to prevent issues + * This fixes a data inconsistency where empty arrays are sent + * for color properties: attcol, sigcol, eyecol, facial + * Reference: Issue #832 + */ ``` </blockquote></details> <details> <summary>src/services/missionInventoryUpdateService.ts (1)</summary><blockquote> `149-153`: **Consider adding error handling for invalid equipment types.** While the dynamic equipment handling is good, it could benefit from additional error handling. ```diff if (equipmentKeys.includes(key as TEquipmentKey)) { + try { addGearExpByCategory(inventory, value as IEquipmentClient[], key as TEquipmentKey); + } catch (error) { + logger.error(`Failed to update XP for equipment type ${key}:`, error); + } } ``` </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: .coderabbit.yaml** **Review profile: CHILL** **Plan: Pro** <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between b72a0d12eff3a3aa598f5fd59e79e9420b18a374 and ac41c6321ce8ebf94fd37b791ddd2efd503610bc. </details> <details> <summary>📒 Files selected for processing (7)</summary> * `src/models/inventoryModels/inventoryModel.ts` (4 hunks) * `src/services/importService.ts` (3 hunks) * `src/services/missionInventoryUpdateService.ts` (3 hunks) * `src/services/saveLoadoutService.ts` (2 hunks) * `src/types/inventoryTypes/commonInventoryTypes.ts` (3 hunks) * `src/types/inventoryTypes/inventoryTypes.ts` (4 hunks) * `src/types/requestTypes.ts` (1 hunks) </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🪛 Biome (1.9.4)</summary> <details> <summary>src/models/inventoryModels/inventoryModel.ts</summary> [error] 736-736: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 787-787: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 788-788: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> </details> <details> <summary>🔇 Additional comments (33)</summary><blockquote> <details> <summary>src/types/inventoryTypes/inventoryTypes.ts (5)</summary> `109-119`: **Extended equipmentKeys** Including the new equipment type strings in `equipmentKeys` is consistent with your dynamic approach. Verify that all references to these keys (including UI, services, and test code) are updated accordingly. --- `189-198`: **Synced new client equipment definitions** These additional properties in `IInventoryClient` mirror the expansions in `IInventoryDatabase`. Confirm that calls referencing them in the client layer are properly handled, especially for newly added equipment categories. --- `649-649`: **New IKubrowPetDetailsDatabase interface** This typed interface for Kubrow pet details increases clarity and maintainability. Consider adding a short doc comment explaining standard usage scenarios for future reference. --- `655-655`: **Switched HatchDate to a native Date** Using a native Date can simplify server-side date handling. Ensure that any previously stored `IMongoDate` fields or related code paths are updated to avoid inconsistencies. --- `662-665`: **Introduced IKubrowPetDetailsClient** This client-side interface correctly replaces `HatchDate` with `IMongoDate`, matching patterns elsewhere in the codebase that return date-like fields to the client. No issues found. </details> <details> <summary>src/models/inventoryModels/inventoryModel.ts (22)</summary> `55-60`: **Updated imports for inventory types** These added imports (including `TEquipmentKey` and `IKubrowPetDetailsClient`) align with the extended equipment system. Confirm all references to the new types stay consistent across the codebase. --- `702-716`: **New traitsSchema for Kubrow pets** Defining a dedicated schema for pet traits (base color, personality, etc.) provides clarity. If certain fields can be absent, mark them optional to reflect real-world usage. --- `717-717`: **Empty line** No changes needed. --- `718-732`: **detalisSchema for Kubrow pet details** Fields like `Name`, `IsPuppy`, and `HasCollar` expand pet functionality. The schema naming aligns well with the rest of the code; keep it consistent in references. --- `733-733`: **Empty line** No changes needed. --- `745-776`: **Enhanced EquipmentSchema** Adding fields like `Weapon`, `Customization`, `CrewMembers`, and `Details` expands equipment to cover new scenarios (Railjack, Kubrow, etc.). This broadens the schema's utility without obvious issues. --- `777-777`: **Empty line** No changes needed. --- `778-778`: **Empty line** No changes needed. --- `779-779`: **Empty line** No changes needed. --- `780-782`: **ItemId virtual property in EquipmentSchema** This virtual property generation is consistent with the rest of your schemas, preserving a consistent client ID format. --- `783-783`: **Empty line** No changes needed. --- `798-798`: **Empty line** No changes needed. --- `800-800`: **Empty line** No changes needed. --- `801-803`: **Populating dynamic equipment arrays** Using `forEach` with `equipmentKeys` demonstrates a clean approach to constructing the schema. --- `804-804`: **Empty line** No changes needed. --- `805-817`: **infestedFoundrySchema additions** Properties like `LastConsumedSuit` and `AbilityOverrideUnlockCooldown` expand infested foundry functionality. Watch for multi-thread data updates if concurrency is a concern. --- `818-818`: **Empty line** No changes needed. --- `819-819`: **Empty line** No changes needed. --- `820-820`: **Empty line** No changes needed. --- `821-829`: **infestedFoundrySchema toJSON transform** Converting `AbilityOverrideUnlockCooldown` to a Mongo-friendly date is consistent with the code’s date-handling pattern. --- `862-863`: **Spread operator for equipment fields** `...equipmentFields` elegantly injects dynamic equipment arrays into the schema. This fortifies your approach to new gear types. --- `1181-1181`: **Extended InventoryDocumentProps** Mapping `TEquipmentKey` to a `Types.DocumentArray<IEquipmentDatabase>` ensures the schema can store newly introduced category arrays consistently. </details> <details> <summary>src/types/requestTypes.ts (1)</summary> `75-76`: **Adopting dynamic equipment fields** Removing explicit array properties in favor of a mapped type keyed by `TEquipmentKey` is more scalable. Confirm any older usage of direct fields has been refactored accordingly. </details> <details> <summary>src/types/inventoryTypes/commonInventoryTypes.ts (2)</summary> `3-11`: **LGTM! Well-organized imports for new equipment types.** The new imports are properly organized and follow TypeScript best practices. --- `91-100`: **LGTM! Clean interface extension with optional properties.** The IEquipmentClient interface is properly extended with optional properties for crew members and pet details, maintaining backward compatibility. </details> <details> <summary>src/services/saveLoadoutService.ts (1)</summary> `15-15`: **LGTM! Good use of type imports.** The import of equipmentKeys and TEquipmentKey enables type-safe dynamic equipment handling. </details> <details> <summary>src/services/importService.ts (1)</summary> `22-23`: **LGTM! Proper imports for new types.** The imports for Kubrow pet-related types are properly organized. </details> <details> <summary>src/services/missionInventoryUpdateService.ts (1)</summary> `5-5`: **LGTM! Well-organized imports.** The imports are properly organized and follow TypeScript best practices. Also applies to: 25-25 </details> </blockquote></details> </details>

src/services/importService.ts

						
				@ -138,1 +138,4 @@

				const convertKubrowDetails = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => {

				    return {

				        ...client,

coderabbitai[bot] (Migrated from github.com) commented

2025-01-24 16:05:50 -08:00

⚠️ Potential issue

Fix typo in function name.

The function name has a typo: "Detalis" should be "Details".

-const convertKubrowDetalis = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => {
+const convertKubrowDetails = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => {

Don't forget to update all references to this function.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

const convertKubrowDetails = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => {
    return {
        ...client,
        HatchDate: convertDate(client.HatchDate)
    };
};

_:warning: Potential issue_ **Fix typo in function name.** The function name has a typo: "Detalis" should be "Details". ```diff -const convertKubrowDetalis = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => { +const convertKubrowDetails = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => { ``` Don't forget to update all references to this function.  <details> <summary>📝 Committable suggestion</summary> > ‼️ **IMPORTANT** > Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements. `````suggestion const convertKubrowDetails = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => { return { ...client, HatchDate: convertDate(client.HatchDate) }; }; ````` </details>

coderabbitai[bot] (Migrated from github.com) reviewed 2025-01-24 16:11:26 -08:00

coderabbitai[bot] (Migrated from github.com) left a comment

Actionable comments posted: 1

🧹 Nitpick comments (2)

src/services/importService.ts (2)
53-65: Improve the implementation of the Configs array filter.

The current implementation has several areas for improvement:

The comment about "aleca" seems implementation-specific and should be more generic

The nested ternary and multi-level arrow functions reduce readability

Consider this cleaner implementation:
-        /*  fix for
-            "attcol": [],
-            "sigcol": [],
-            "eyecol": [],
-            "facial": [],
-            in data from aleca */
-        Configs: client.Configs
-            ? client.Configs.map(obj =>
-                  Object.fromEntries(
-                      Object.entries(obj).filter(([_, value]) => !Array.isArray(value) || value.length > 0)
-                  )
-              )
-            : []
+        // Remove empty arrays from config objects
+        Configs: client.Configs?.map(config => {
+            const entries = Object.entries(config);
+            const nonEmptyEntries = entries.filter(([_, value]) => 
+                !Array.isArray(value) || value.length > 0
+            );
+            return Object.fromEntries(nonEmptyEntries);
+        }) ?? []
145-150: Consider adding validation for Kubrow-specific fields.

While the basic conversion is implemented correctly, consider adding validation for Kubrow-specific fields to ensure data integrity.

Example implementation with validation:
 const convertKubrowDetails = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => {
+    // Validate required fields
+    if (!client.HatchDate) {
+        throw new Error('HatchDate is required for Kubrow pet details');
+    }
+
     return {
         ...client,
         HatchDate: convertDate(client.HatchDate)
     };
 };

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ac41c6321c and 2962ec871e.

📒 Files selected for processing (1)

src/services/importService.ts (3 hunks)

🔇 Additional comments (1)

src/services/importService.ts (1)

22-23: LGTM! New type imports for Kubrow pet details.

The addition of Kubrow pet detail types aligns with the PR objective of supporting more equipment types.

**Actionable comments posted: 1** <details> <summary>🧹 Nitpick comments (2)</summary><blockquote> <details> <summary>src/services/importService.ts (2)</summary><blockquote> `53-65`: **Improve the implementation of the Configs array filter.** The current implementation has several areas for improvement: 1. The comment about "aleca" seems implementation-specific and should be more generic 2. The nested ternary and multi-level arrow functions reduce readability Consider this cleaner implementation: ```diff - /* fix for - "attcol": [], - "sigcol": [], - "eyecol": [], - "facial": [], - in data from aleca */ - Configs: client.Configs - ? client.Configs.map(obj => - Object.fromEntries( - Object.entries(obj).filter(([_, value]) => !Array.isArray(value) || value.length > 0) - ) - ) - : [] + // Remove empty arrays from config objects + Configs: client.Configs?.map(config => { + const entries = Object.entries(config); + const nonEmptyEntries = entries.filter(([_, value]) => + !Array.isArray(value) || value.length > 0 + ); + return Object.fromEntries(nonEmptyEntries); + }) ?? [] ``` --- `145-150`: **Consider adding validation for Kubrow-specific fields.** While the basic conversion is implemented correctly, consider adding validation for Kubrow-specific fields to ensure data integrity. Example implementation with validation: ```diff const convertKubrowDetails = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => { + // Validate required fields + if (!client.HatchDate) { + throw new Error('HatchDate is required for Kubrow pet details'); + } + return { ...client, HatchDate: convertDate(client.HatchDate) }; }; ``` </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: .coderabbit.yaml** **Review profile: CHILL** **Plan: Pro** <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between ac41c6321ce8ebf94fd37b791ddd2efd503610bc and 2962ec871e2ea614c6da1f767628e6cb0602c639. </details> <details> <summary>📒 Files selected for processing (1)</summary> * `src/services/importService.ts` (3 hunks) </details> <details> <summary>🔇 Additional comments (1)</summary><blockquote> <details> <summary>src/services/importService.ts (1)</summary> `22-23`: **LGTM! New type imports for Kubrow pet details.** The addition of Kubrow pet detail types aligns with the PR objective of supporting more equipment types. </details> </blockquote></details> </details>

src/services/importService.ts

coderabbitai[bot] (Migrated from github.com) commented

2025-01-24 16:11:25 -08:00

💡 Codebase verification

Crew ship functionality appears partially removed

The codebase shows signs of incomplete removal of crew ship functionality:

The convertCrewShipMembers function is referenced but not implemented
Only type definitions remain with no active implementation
The current code appears to be a leftover that should be removed

🔗 Analysis chain

Verify the inclusion of crew ship functionality.

The AI summary indicates that crew ship functionality is being removed, but this line still processes crew ship members. Please clarify if crew ship support should be maintained.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for other crew ship related code that might need to be removed
rg -l 'CrewShip|CrewMember' --type ts

Length of output: 407

Script:

#!/bin/bash
# Check recent changes to crew-related files and look for implementation details
echo "=== Recent changes to crew-related files ==="
git log --oneline -n 5 -- src/services/importService.ts src/services/serversideVendorsService.ts src/services/inventoryService.ts

echo -e "\n=== Crew implementation details ==="
ast-grep --pattern 'function $FUNC($$$) { $$$ CrewMember $$$ }'

echo -e "\n=== Type definitions ==="
rg "interface.*CrewMember" --type ts -A 2

Length of output: 574

Script:

#!/bin/bash
# Check the implementation details in importService.ts
echo "=== CrewMembers conversion implementation ==="
rg "function convertCrewShipMembers" --type ts -A 5

echo -e "\n=== CrewMembers usage ==="
rg "CrewMembers" src/services/importService.ts -B 2 -A 2

Length of output: 600

_:bulb: Codebase verification_ **Crew ship functionality appears partially removed** The codebase shows signs of incomplete removal of crew ship functionality: - The `convertCrewShipMembers` function is referenced but not implemented - Only type definitions remain with no active implementation - The current code appears to be a leftover that should be removed <details> <summary>🔗 Analysis chain</summary> **Verify the inclusion of crew ship functionality.** The AI summary indicates that crew ship functionality is being removed, but this line still processes crew ship members. Please clarify if crew ship support should be maintained. </details> <details> <summary>🏁 Scripts executed</summary> The following scripts were executed for the analysis: Script: ```shell #!/bin/bash # Search for other crew ship related code that might need to be removed rg -l 'CrewShip|CrewMember' --type ts ``` Length of output: 407 --- Script: ```shell #!/bin/bash # Check recent changes to crew-related files and look for implementation details echo "=== Recent changes to crew-related files ===" git log --oneline -n 5 -- src/services/importService.ts src/services/serversideVendorsService.ts src/services/inventoryService.ts echo -e "\n=== Crew implementation details ===" ast-grep --pattern 'function $FUNC($$$) { $$$ CrewMember $$$ }' echo -e "\n=== Type definitions ===" rg "interface.*CrewMember" --type ts -A 2 ``` Length of output: 574 --- Script: ```shell #!/bin/bash # Check the implementation details in importService.ts echo "=== CrewMembers conversion implementation ===" rg "function convertCrewShipMembers" --type ts -A 5 echo -e "\n=== CrewMembers usage ===" rg "CrewMembers" src/services/importService.ts -B 2 -A 2 ``` Length of output: 600 </details>

AMelonInsideLemon (Migrated from github.com) reviewed 2025-01-24 16:15:25 -08:00

src/services/importService.ts

AMelonInsideLemon (Migrated from github.com) commented

2025-01-24 16:15:25 -08:00

You are blind?

const convertCrewShipMembers = (client: ICrewShipMembersClient): ICrewShipMembersDatabase => {
    return {
        SLOT_A: client.SLOT_A ? convertCrewShipMember(client.SLOT_A) : undefined,
        SLOT_B: client.SLOT_B ? convertCrewShipMember(client.SLOT_B) : undefined,
        SLOT_C: client.SLOT_C ? convertCrewShipMember(client.SLOT_C) : undefined
    };
};

You are blind? ``` const convertCrewShipMembers = (client: ICrewShipMembersClient): ICrewShipMembersDatabase => { return { SLOT_A: client.SLOT_A ? convertCrewShipMember(client.SLOT_A) : undefined, SLOT_B: client.SLOT_B ? convertCrewShipMember(client.SLOT_B) : undefined, SLOT_C: client.SLOT_C ? convertCrewShipMember(client.SLOT_C) : undefined }; }; ```

coderabbitai[bot] (Migrated from github.com) reviewed 2025-01-24 16:15:45 -08:00

src/services/importService.ts

coderabbitai[bot] (Migrated from github.com) commented

2025-01-24 16:15:45 -08:00

@AMelonInsideLemon I apologize for my oversight. You are absolutely correct - the convertCrewShipMembers function is clearly implemented in the code. I made a mistake in my analysis.

(｡•́︿•̀｡)

✏️ Learnings added

Learnt from: AMelonInsideLemon
PR: spaceninjaserver/SpaceNinjaServer#867
File: src/services/importService.ts:51-51
Timestamp: 2025-01-25T00:15:43.724Z
Learning: The `convertCrewShipMembers` function in `src/services/importService.ts` handles the conversion of crew ship members with three slots (A, B, C), and is actively used in the codebase for crew ship functionality.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

@AMelonInsideLemon I apologize for my oversight. You are absolutely correct - the `convertCrewShipMembers` function is clearly implemented in the code. I made a mistake in my analysis. (｡•́︿•̀｡) --- <details> <summary>✏️ Learnings added</summary> ``` Learnt from: AMelonInsideLemon PR: spaceninjaserver/SpaceNinjaServer#867 File: src/services/importService.ts:51-51 Timestamp: 2025-01-25T00:15:43.724Z Learning: The `convertCrewShipMembers` function in `src/services/importService.ts` handles the conversion of crew ship members with three slots (A, B, C), and is actively used in the codebase for crew ship functionality. ``` > Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure [review instructions](https://docs.coderabbit.ai/guides/review-instructions). You can manage existing learnings in the [app](https://app.coderabbit.ai/learnings). </details>

Sainan approved these changes 2025-01-24 21:24:45 -08:00

coderabbitai[bot] (Migrated from github.com) reviewed 2025-01-25 05:27:48 -08:00

coderabbitai[bot] (Migrated from github.com) left a comment

Actionable comments posted: 0

🧹 Nitpick comments (4)

src/services/saveLoadoutService.ts (1)
144-166: Enhance error message in the default case.

The warning message could be more descriptive to help with debugging.
-                    logger.warn(`loadout category not implemented, changes may be lost: ${equipmentName}`, {
+                    logger.warn(`Unhandled loadout category '${equipmentName}'. Changes will not be persisted. Add to equipmentKeys if this is a new equipment type.`, {
                         config: equipment
                     });
src/models/inventoryModels/inventoryModel.ts (3)
718-718: Fix typo in schema name.

The schema name detalisSchema contains a typo and should be renamed to detailsSchema for better clarity and consistency.
-const detalisSchema = new Schema<IKubrowPetDetailsDatabase>(
+const detailsSchema = new Schema<IKubrowPetDetailsDatabase>(
745-778: Consider decomposing the EquipmentSchema into specialized sub-schemas.

The schema currently handles multiple equipment types (weapons, customizations, pets) in a single definition. Consider breaking it down into specialized sub-schemas for better maintainability and separation of concerns.

Example approach:
const BaseEquipmentSchema = new Schema({
  ItemType: String,
  Configs: [ItemConfigSchema],
  // ... common fields
});

const WeaponEquipmentSchema = new Schema({
  ...BaseEquipmentSchema.obj,
  Weapon: crewShipWeaponSchema,
  // ... weapon-specific fields
});

const PetEquipmentSchema = new Schema({
  ...BaseEquipmentSchema.obj,
  Details: detailsSchema,
  // ... pet-specific fields
});

// Then use discriminators to handle different types
const EquipmentSchema = new Schema({
  ...BaseEquipmentSchema.obj,
  equipmentType: { type: String, required: true }
});

EquipmentSchema.discriminator('Weapon', WeaponEquipmentSchema);
EquipmentSchema.discriminator('Pet', PetEquipmentSchema);
734-743: Optimize JSON transformations for better performance.

The use of the delete operator in transform functions can impact performance. Consider using undefined assignments or selective field copying instead.
 transform(_doc, returnedObject) {
-    delete returnedObject.__v;
+    returnedObject.__v = undefined;

     const db = returnedObject as IKubrowPetDetailsDatabase;
     const client = returnedObject as IKubrowPetDetailsClient;

     client.HatchDate = toMongoDate(db.HatchDate);
 }
Similar changes should be applied to other transform functions in the file.

Also applies to: 784-797

🧰 Tools

🪛 Biome (1.9.4)

[error] 736-736: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2962ec871e and 9dd1032128.

📒 Files selected for processing (5)

src/models/inventoryModels/inventoryModel.ts (5 hunks)
src/services/importService.ts (4 hunks)
src/services/saveLoadoutService.ts (3 hunks)
src/types/inventoryTypes/inventoryTypes.ts (6 hunks)
src/types/saveLoadoutTypes.ts (1 hunks)

🧰 Additional context used

📓 Learnings (1)

src/services/importService.ts (1)

Learnt from: AMelonInsideLemon
PR: spaceninjaserver/SpaceNinjaServer#867
File: src/services/importService.ts:51-51
Timestamp: 2025-01-25T00:15:43.894Z
Learning: The `convertCrewShipMembers` function in `src/services/importService.ts` handles the conversion of crew ship members with three slots (A, B, C), and is actively used in the codebase for crew ship functionality.

🪛 Biome (1.9.4)

src/models/inventoryModels/inventoryModel.ts

[error] 736-736: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 787-787: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 788-788: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

🔇 Additional comments (10)

src/types/saveLoadoutTypes.ts (1)

31-32: LGTM! The interface changes look good.

The addition of OperatorLoadOuts and KahlLoadOuts properties to ISaveLoadoutRequest interface is consistent with the existing pattern and properly typed.

src/services/saveLoadoutService.ts (2)

15-15: LGTM! Good use of type-safe equipment keys.

The import of equipmentKeys and TEquipmentKey enables type-safe handling of equipment types.

40-42: LGTM! Consistent handling of operator loadouts.

The case statements for AdultOperatorLoadOuts, OperatorLoadOuts, and KahlLoadOuts follow the same pattern, making the code maintainable.

src/services/importService.ts (2)

51-52: LGTM! Proper handling of crew members and details.

The conversion of CrewMembers and Details in convertEquipment is consistent with the existing patterns.

145-150: LGTM! Well-structured Kubrow details conversion.

The convertKubrowDetails function properly handles the date conversion for HatchDate.

src/types/inventoryTypes/inventoryTypes.ts (3)

71-80: LGTM! Comprehensive addition of new equipment types.

The new equipment types are properly added to IInventoryDatabase with consistent typing.

110-120: LGTM! Updated equipment keys array.

The equipmentKeys array is properly updated to include all new equipment types, maintaining type safety.

650-665: LGTM! Well-structured Kubrow pet details interfaces.

The separation of client and database interfaces for Kubrow pet details properly handles the date type differences:

IKubrowPetDetailsDatabase uses Date

IKubrowPetDetailsClient uses IMongoDate

src/models/inventoryModels/inventoryModel.ts (2)

702-716: LGTM! Well-structured pet traits and details schemas.

The implementation provides a clear separation of concerns between traits and details, with proper type safety and date handling.

Also applies to: 718-743

799-803: LGTM! Excellent dynamic equipment fields implementation.

The dynamic field generation using equipmentKeys provides a flexible and type-safe way to extend equipment types. The implementation follows MongoDB/Mongoose best practices.

Also applies to: 862-862

**Actionable comments posted: 0** <details> <summary>🧹 Nitpick comments (4)</summary><blockquote> <details> <summary>src/services/saveLoadoutService.ts (1)</summary><blockquote> `144-166`: **Enhance error message in the default case.** The warning message could be more descriptive to help with debugging. ```diff - logger.warn(`loadout category not implemented, changes may be lost: ${equipmentName}`, { + logger.warn(`Unhandled loadout category '${equipmentName}'. Changes will not be persisted. Add to equipmentKeys if this is a new equipment type.`, { config: equipment }); ``` </blockquote></details> <details> <summary>src/models/inventoryModels/inventoryModel.ts (3)</summary><blockquote> `718-718`: **Fix typo in schema name.** The schema name `detalisSchema` contains a typo and should be renamed to `detailsSchema` for better clarity and consistency. ```diff -const detalisSchema = new Schema<IKubrowPetDetailsDatabase>( +const detailsSchema = new Schema<IKubrowPetDetailsDatabase>( ``` --- `745-778`: **Consider decomposing the EquipmentSchema into specialized sub-schemas.** The schema currently handles multiple equipment types (weapons, customizations, pets) in a single definition. Consider breaking it down into specialized sub-schemas for better maintainability and separation of concerns. Example approach: ```typescript const BaseEquipmentSchema = new Schema({ ItemType: String, Configs: [ItemConfigSchema], // ... common fields }); const WeaponEquipmentSchema = new Schema({ ...BaseEquipmentSchema.obj, Weapon: crewShipWeaponSchema, // ... weapon-specific fields }); const PetEquipmentSchema = new Schema({ ...BaseEquipmentSchema.obj, Details: detailsSchema, // ... pet-specific fields }); // Then use discriminators to handle different types const EquipmentSchema = new Schema({ ...BaseEquipmentSchema.obj, equipmentType: { type: String, required: true } }); EquipmentSchema.discriminator('Weapon', WeaponEquipmentSchema); EquipmentSchema.discriminator('Pet', PetEquipmentSchema); ``` --- `734-743`: **Optimize JSON transformations for better performance.** The use of the `delete` operator in transform functions can impact performance. Consider using undefined assignments or selective field copying instead. ```diff transform(_doc, returnedObject) { - delete returnedObject.__v; + returnedObject.__v = undefined; const db = returnedObject as IKubrowPetDetailsDatabase; const client = returnedObject as IKubrowPetDetailsClient; client.HatchDate = toMongoDate(db.HatchDate); } ``` Similar changes should be applied to other transform functions in the file. Also applies to: 784-797 <details> <summary>🧰 Tools</summary> <details> <summary>🪛 Biome (1.9.4)</summary> [error] 736-736: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: .coderabbit.yaml** **Review profile: CHILL** **Plan: Pro** <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 2962ec871e2ea614c6da1f767628e6cb0602c639 and 9dd1032128218ebc82d9c258e011be68080922c4. </details> <details> <summary>📒 Files selected for processing (5)</summary> * `src/models/inventoryModels/inventoryModel.ts` (5 hunks) * `src/services/importService.ts` (4 hunks) * `src/services/saveLoadoutService.ts` (3 hunks) * `src/types/inventoryTypes/inventoryTypes.ts` (6 hunks) * `src/types/saveLoadoutTypes.ts` (1 hunks) </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>📓 Learnings (1)</summary> <details> <summary>src/services/importService.ts (1)</summary> ``` Learnt from: AMelonInsideLemon PR: spaceninjaserver/SpaceNinjaServer#867 File: src/services/importService.ts:51-51 Timestamp: 2025-01-25T00:15:43.894Z Learning: The `convertCrewShipMembers` function in `src/services/importService.ts` handles the conversion of crew ship members with three slots (A, B, C), and is actively used in the codebase for crew ship functionality. ``` </details> </details><details> <summary>🪛 Biome (1.9.4)</summary> <details> <summary>src/models/inventoryModels/inventoryModel.ts</summary> [error] 736-736: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 787-787: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 788-788: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> </details> <details> <summary>🔇 Additional comments (10)</summary><blockquote> <details> <summary>src/types/saveLoadoutTypes.ts (1)</summary> `31-32`: **LGTM! The interface changes look good.** The addition of `OperatorLoadOuts` and `KahlLoadOuts` properties to `ISaveLoadoutRequest` interface is consistent with the existing pattern and properly typed. </details> <details> <summary>src/services/saveLoadoutService.ts (2)</summary> `15-15`: **LGTM! Good use of type-safe equipment keys.** The import of `equipmentKeys` and `TEquipmentKey` enables type-safe handling of equipment types. --- `40-42`: **LGTM! Consistent handling of operator loadouts.** The case statements for `AdultOperatorLoadOuts`, `OperatorLoadOuts`, and `KahlLoadOuts` follow the same pattern, making the code maintainable. </details> <details> <summary>src/services/importService.ts (2)</summary> `51-52`: **LGTM! Proper handling of crew members and details.** The conversion of `CrewMembers` and `Details` in `convertEquipment` is consistent with the existing patterns. --- `145-150`: **LGTM! Well-structured Kubrow details conversion.** The `convertKubrowDetails` function properly handles the date conversion for `HatchDate`. </details> <details> <summary>src/types/inventoryTypes/inventoryTypes.ts (3)</summary> `71-80`: **LGTM! Comprehensive addition of new equipment types.** The new equipment types are properly added to `IInventoryDatabase` with consistent typing. --- `110-120`: **LGTM! Updated equipment keys array.** The `equipmentKeys` array is properly updated to include all new equipment types, maintaining type safety. --- `650-665`: **LGTM! Well-structured Kubrow pet details interfaces.** The separation of client and database interfaces for Kubrow pet details properly handles the date type differences: - `IKubrowPetDetailsDatabase` uses `Date` - `IKubrowPetDetailsClient` uses `IMongoDate` </details> <details> <summary>src/models/inventoryModels/inventoryModel.ts (2)</summary> `702-716`: **LGTM! Well-structured pet traits and details schemas.** The implementation provides a clear separation of concerns between traits and details, with proper type safety and date handling. Also applies to: 718-743 --- `799-803`: **LGTM! Excellent dynamic equipment fields implementation.** The dynamic field generation using `equipmentKeys` provides a flexible and type-safe way to extend equipment types. The implementation follows MongoDB/Mongoose best practices. Also applies to: 862-862 </details> </blockquote></details> </details>

OrdisPrime (Migrated from github.com) reviewed 2025-01-25 14:22:36 -08:00

src/models/inventoryModels/inventoryModel.ts

OrdisPrime (Migrated from github.com) commented

2025-01-24 17:10:48 -08:00

Record<string, any> is not good.

src/services/importService.ts

OrdisPrime (Migrated from github.com) commented

2025-01-24 17:15:15 -08:00

lets not do advertisements for them here

coderabbitai[bot] (Migrated from github.com) reviewed 2025-01-25 23:13:57 -08:00

coderabbitai[bot] (Migrated from github.com) left a comment

Actionable comments posted: 1

🧹 Nitpick comments (6)

src/services/importService.ts (2)
50-59: Simplify the array filtering logic.

The array filtering logic in the Configs mapping could be simplified for better readability.

Consider this refactor:
-        Configs: client.Configs
-            ? client.Configs.map(obj =>
-                  Object.fromEntries(
-                      Object.entries(obj).filter(([_, value]) => !Array.isArray(value) || value.length > 0)
-                  )
-              )
-            : []
+        Configs: client.Configs?.map(obj => {
+            const entries = Object.entries(obj);
+            const nonEmptyEntries = entries.filter(([_, value]) => !Array.isArray(value) || value.length > 0);
+            return Object.fromEntries(nonEmptyEntries);
+        }) ?? []
139-144: Add error handling for date conversion.

The function should handle potential invalid dates to prevent runtime errors.

Consider this improvement:
 const convertKubrowDetails = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => {
+    if (!client.HatchDate) {
+        throw new Error('HatchDate is required for Kubrow pet details');
+    }
     return {
         ...client,
         HatchDate: convertDate(client.HatchDate)
     };
 };
src/models/inventoryModels/inventoryModel.ts (4)
702-716: Add validation for color fields.

The schema should validate color formats to ensure data consistency.

Consider adding validation:
 const traitsSchema = new Schema<ITraits>(
     {
-        BaseColor: String,
+        BaseColor: {
+            type: String,
+            validate: {
+                validator: (v: string) => /^[A-F0-9]{6}$/i.test(v),
+                message: 'Color must be a valid hex color code'
+            }
+        },
         // Apply similar validation to other color fields
     },
     { _id: false }
 );
734-743: Optimize schema transformation performance.

Using the delete operator can impact performance. Consider using undefined assignment instead.

Apply this optimization:
 detalisSchema.set("toJSON", {
     transform(_doc, returnedObject) {
-        delete returnedObject.__v;
+        returnedObject.__v = undefined;
 
         const db = returnedObject as IKubrowPetDetailsDatabase;
         const client = returnedObject as IKubrowPetDetailsClient;
 
         client.HatchDate = toMongoDate(db.HatchDate);
     }
 });
🧰 Tools

🪛 Biome (1.9.4)

[error] 736-736: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

745-798: Optimize schema transformation and add validation.

The schema transformation can be optimized, and validation should be added for critical fields.

Consider these improvements:
 EquipmentSchema.set("toJSON", {
     virtuals: true,
     transform(_document, returnedObject) {
-        delete returnedObject._id;
-        delete returnedObject.__v;
+        returnedObject._id = undefined;
+        returnedObject.__v = undefined;
 
         const db = returnedObject as IEquipmentDatabase;
         const client = returnedObject as IEquipmentClient;
 
         if (db.InfestationDate) {
             client.InfestationDate = toMongoDate(db.InfestationDate);
         }
     }
 });
Also, consider adding validation for critical fields like ItemType:
ItemType: {
    type: String,
    required: true,
    validate: {
        validator: (v: string) => v.startsWith('/Lotus/Types/'),
        message: 'ItemType must be a valid Warframe item path'
    }
}
🧰 Tools

🪛 Biome (1.9.4)

[error] 787-787: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 788-788: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

799-804: Improve type safety for dynamic equipment fields.

Using Record<string, any> reduces type safety. Consider using a more specific type.

Apply this improvement:
-const equipmentFields: Record<string, { type: (typeof EquipmentSchema)[] }> = {};
+const equipmentFields: { [K in TEquipmentKey]: { type: (typeof EquipmentSchema)[] } } = {} as { [K in TEquipmentKey]: { type: (typeof EquipmentSchema)[] } };

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9dd1032128 and 73cda21f6d.

📒 Files selected for processing (2)

src/models/inventoryModels/inventoryModel.ts (5 hunks)
src/services/importService.ts (4 hunks)

🧰 Additional context used

📓 Learnings (1)

src/services/importService.ts (1)

Learnt from: AMelonInsideLemon
PR: spaceninjaserver/SpaceNinjaServer#867
File: src/services/importService.ts:51-51
Timestamp: 2025-01-25T00:15:43.894Z
Learning: The `convertCrewShipMembers` function in `src/services/importService.ts` handles the conversion of crew ship members with three slots (A, B, C), and is actively used in the codebase for crew ship functionality.

🪛 Biome (1.9.4)

src/models/inventoryModels/inventoryModel.ts

[error] 736-736: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 787-787: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 788-788: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

🔇 Additional comments (1)

src/services/importService.ts (1)

22-23: LGTM!

The new imports for Kubrow pet details types align with the PR objective.

**Actionable comments posted: 1** <details> <summary>🧹 Nitpick comments (6)</summary><blockquote> <details> <summary>src/services/importService.ts (2)</summary><blockquote> `50-59`: **Simplify the array filtering logic.** The array filtering logic in the Configs mapping could be simplified for better readability. Consider this refactor: ```diff - Configs: client.Configs - ? client.Configs.map(obj => - Object.fromEntries( - Object.entries(obj).filter(([_, value]) => !Array.isArray(value) || value.length > 0) - ) - ) - : [] + Configs: client.Configs?.map(obj => { + const entries = Object.entries(obj); + const nonEmptyEntries = entries.filter(([_, value]) => !Array.isArray(value) || value.length > 0); + return Object.fromEntries(nonEmptyEntries); + }) ?? [] ``` --- `139-144`: **Add error handling for date conversion.** The function should handle potential invalid dates to prevent runtime errors. Consider this improvement: ```diff const convertKubrowDetails = (client: IKubrowPetDetailsClient): IKubrowPetDetailsDatabase => { + if (!client.HatchDate) { + throw new Error('HatchDate is required for Kubrow pet details'); + } return { ...client, HatchDate: convertDate(client.HatchDate) }; }; ``` </blockquote></details> <details> <summary>src/models/inventoryModels/inventoryModel.ts (4)</summary><blockquote> `702-716`: **Add validation for color fields.** The schema should validate color formats to ensure data consistency. Consider adding validation: ```diff const traitsSchema = new Schema<ITraits>( { - BaseColor: String, + BaseColor: { + type: String, + validate: { + validator: (v: string) => /^[A-F0-9]{6}$/i.test(v), + message: 'Color must be a valid hex color code' + } + }, // Apply similar validation to other color fields }, { _id: false } ); ``` --- `734-743`: **Optimize schema transformation performance.** Using the delete operator can impact performance. Consider using undefined assignment instead. Apply this optimization: ```diff detalisSchema.set("toJSON", { transform(_doc, returnedObject) { - delete returnedObject.__v; + returnedObject.__v = undefined; const db = returnedObject as IKubrowPetDetailsDatabase; const client = returnedObject as IKubrowPetDetailsClient; client.HatchDate = toMongoDate(db.HatchDate); } }); ``` <details> <summary>🧰 Tools</summary> <details> <summary>🪛 Biome (1.9.4)</summary> [error] 736-736: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> --- `745-798`: **Optimize schema transformation and add validation.** The schema transformation can be optimized, and validation should be added for critical fields. Consider these improvements: ```diff EquipmentSchema.set("toJSON", { virtuals: true, transform(_document, returnedObject) { - delete returnedObject._id; - delete returnedObject.__v; + returnedObject._id = undefined; + returnedObject.__v = undefined; const db = returnedObject as IEquipmentDatabase; const client = returnedObject as IEquipmentClient; if (db.InfestationDate) { client.InfestationDate = toMongoDate(db.InfestationDate); } } }); ``` Also, consider adding validation for critical fields like ItemType: ```typescript ItemType: { type: String, required: true, validate: { validator: (v: string) => v.startsWith('/Lotus/Types/'), message: 'ItemType must be a valid Warframe item path' } } ``` <details> <summary>🧰 Tools</summary> <details> <summary>🪛 Biome (1.9.4)</summary> [error] 787-787: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 788-788: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> --- `799-804`: **Improve type safety for dynamic equipment fields.** Using `Record<string, any>` reduces type safety. Consider using a more specific type. Apply this improvement: ```diff -const equipmentFields: Record<string, { type: (typeof EquipmentSchema)[] }> = {}; +const equipmentFields: { [K in TEquipmentKey]: { type: (typeof EquipmentSchema)[] } } = {} as { [K in TEquipmentKey]: { type: (typeof EquipmentSchema)[] } }; ``` </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: .coderabbit.yaml** **Review profile: CHILL** **Plan: Pro** <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 9dd1032128218ebc82d9c258e011be68080922c4 and 73cda21f6de28395dee104035ff7f3638ede1b36. </details> <details> <summary>📒 Files selected for processing (2)</summary> * `src/models/inventoryModels/inventoryModel.ts` (5 hunks) * `src/services/importService.ts` (4 hunks) </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>📓 Learnings (1)</summary> <details> <summary>src/services/importService.ts (1)</summary> ``` Learnt from: AMelonInsideLemon PR: spaceninjaserver/SpaceNinjaServer#867 File: src/services/importService.ts:51-51 Timestamp: 2025-01-25T00:15:43.894Z Learning: The `convertCrewShipMembers` function in `src/services/importService.ts` handles the conversion of crew ship members with three slots (A, B, C), and is actively used in the codebase for crew ship functionality. ``` </details> </details><details> <summary>🪛 Biome (1.9.4)</summary> <details> <summary>src/models/inventoryModels/inventoryModel.ts</summary> [error] 736-736: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 787-787: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 788-788: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> </details> <details> <summary>🔇 Additional comments (1)</summary><blockquote> <details> <summary>src/services/importService.ts (1)</summary> `22-23`: **LGTM!** The new imports for Kubrow pet details types align with the PR objective. </details> </blockquote></details> </details>

src/models/inventoryModels/inventoryModel.ts

coderabbitai[bot] (Migrated from github.com) commented

2025-01-25 23:13:57 -08:00

⚠️ Potential issue

Fix typo in schema name.

The schema name has a typo: "detalis" should be "details".

Apply this fix:

-const detalisSchema = new Schema<IKubrowPetDetailsDatabase>(
+const detailsSchema = new Schema<IKubrowPetDetailsDatabase>(

Remember to update all references to this schema.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

const detailsSchema = new Schema<IKubrowPetDetailsDatabase>(
    {
        Name: String,
        IsPuppy: Boolean,
        HasCollar: Boolean,
        PrintsRemaining: Number,
        Status: String,
        HatchDate: Date,
        DominantTraits: traitsSchema,
        RecessiveTraits: traitsSchema,
        IsMale: Boolean,
        Size: Number
    },
    { _id: false }
);

_:warning: Potential issue_ **Fix typo in schema name.** The schema name has a typo: "detalis" should be "details". Apply this fix: ```diff -const detalisSchema = new Schema<IKubrowPetDetailsDatabase>( +const detailsSchema = new Schema<IKubrowPetDetailsDatabase>( ``` Remember to update all references to this schema.  <details> <summary>📝 Committable suggestion</summary> > ‼️ **IMPORTANT** > Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements. `````suggestion const detailsSchema = new Schema<IKubrowPetDetailsDatabase>( { Name: String, IsPuppy: Boolean, HasCollar: Boolean, PrintsRemaining: Number, Status: String, HatchDate: Date, DominantTraits: traitsSchema, RecessiveTraits: traitsSchema, IsMale: Boolean, Size: Number }, { _id: false } ); ````` </details>

coderabbitai[bot] (Migrated from github.com) reviewed 2025-01-25 23:21:29 -08:00

coderabbitai[bot] (Migrated from github.com) left a comment

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/models/inventoryModels/inventoryModel.ts (1)
784-797: Optimize toJSON transform to avoid delete operator.

The delete operator usage can impact performance. Consider using undefined assignment instead.
 EquipmentSchema.set("toJSON", {
     virtuals: true,
     transform(_document, returnedObject) {
-        delete returnedObject._id;
-        delete returnedObject.__v;
+        returnedObject._id = undefined;
+        returnedObject.__v = undefined;

         const db = returnedObject as IEquipmentDatabase;
         const client = returnedObject as IEquipmentClient;

         if (db.InfestationDate) {
             client.InfestationDate = toMongoDate(db.InfestationDate);
         }
     }
 });
🧰 Tools

🪛 Biome (1.9.4)

[error] 787-787: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 788-788: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 73cda21f6d and 99ab187724.

📒 Files selected for processing (1)

src/models/inventoryModels/inventoryModel.ts (5 hunks)

🧰 Additional context used

🪛 Biome (1.9.4)

src/models/inventoryModels/inventoryModel.ts

[error] 736-736: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 787-787: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

[error] 788-788: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

🔇 Additional comments (5)

src/models/inventoryModels/inventoryModel.ts (5)

702-743: LGTM! Well-structured schema definitions for pet traits and details.

The new schemas are well-organized, properly typed, and follow MongoDB best practices. The date transformation for HatchDate is correctly implemented.

🧰 Tools

🪛 Biome (1.9.4)

[error] 736-736: Avoid the delete operator which can impact performance.

Unsafe fix: Use an undefined assignment instead.

(lint/performance/noDelete)

745-776: LGTM! Well-structured equipment schema with comprehensive field definitions.

The schema has been expanded to include new equipment types while maintaining proper typing and MongoDB best practices.

799-803: LGTM! Excellent implementation of dynamic equipment fields.

The dynamic generation of equipment fields using equipmentKeys provides flexibility and maintainability for adding new equipment types.

937-938: LGTM! Well-integrated inventory schema changes.

The addition of KahlLoadOuts and integration of dynamic equipment fields maintains type safety and follows MongoDB best practices.

Also applies to: 862-862, 1181-1181

805-828: LGTM! Well-structured infested foundry schema with proper date handling.

The schema correctly integrates with the EquipmentSchema for LastConsumedSuit and properly handles date transformation.

Consider removing the eslint-disable comment by properly typing the ret parameter:
 infestedFoundrySchema.set("toJSON", {
-    transform(_doc, ret, _options) {
+    transform(_doc, ret: IInfestedFoundryDatabase, _options) {
         if (ret.AbilityOverrideUnlockCooldown) {
-            // eslint-disable-next-line @typescript-eslint/no-unsafe-argument
             ret.AbilityOverrideUnlockCooldown = toMongoDate(ret.AbilityOverrideUnlockCooldown);
         }
     }
 });

**Actionable comments posted: 0** <details> <summary>🧹 Nitpick comments (1)</summary><blockquote> <details> <summary>src/models/inventoryModels/inventoryModel.ts (1)</summary><blockquote> `784-797`: **Optimize toJSON transform to avoid delete operator.** The delete operator usage can impact performance. Consider using undefined assignment instead. ```diff EquipmentSchema.set("toJSON", { virtuals: true, transform(_document, returnedObject) { - delete returnedObject._id; - delete returnedObject.__v; + returnedObject._id = undefined; + returnedObject.__v = undefined; const db = returnedObject as IEquipmentDatabase; const client = returnedObject as IEquipmentClient; if (db.InfestationDate) { client.InfestationDate = toMongoDate(db.InfestationDate); } } }); ``` <details> <summary>🧰 Tools</summary> <details> <summary>🪛 Biome (1.9.4)</summary> [error] 787-787: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 788-788: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: .coderabbit.yaml** **Review profile: CHILL** **Plan: Pro** <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 73cda21f6de28395dee104035ff7f3638ede1b36 and 99ab1877244ced20d52669075a5380e808841e39. </details> <details> <summary>📒 Files selected for processing (1)</summary> * `src/models/inventoryModels/inventoryModel.ts` (5 hunks) </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🪛 Biome (1.9.4)</summary> <details> <summary>src/models/inventoryModels/inventoryModel.ts</summary> [error] 736-736: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 787-787: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) --- [error] 788-788: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> </details> <details> <summary>🔇 Additional comments (5)</summary><blockquote> <details> <summary>src/models/inventoryModels/inventoryModel.ts (5)</summary> `702-743`: **LGTM! Well-structured schema definitions for pet traits and details.** The new schemas are well-organized, properly typed, and follow MongoDB best practices. The date transformation for `HatchDate` is correctly implemented. <details> <summary>🧰 Tools</summary> <details> <summary>🪛 Biome (1.9.4)</summary> [error] 736-736: Avoid the delete operator which can impact performance. Unsafe fix: Use an undefined assignment instead. (lint/performance/noDelete) </details> </details> --- `745-776`: **LGTM! Well-structured equipment schema with comprehensive field definitions.** The schema has been expanded to include new equipment types while maintaining proper typing and MongoDB best practices. --- `799-803`: **LGTM! Excellent implementation of dynamic equipment fields.** The dynamic generation of equipment fields using `equipmentKeys` provides flexibility and maintainability for adding new equipment types. --- `937-938`: **LGTM! Well-integrated inventory schema changes.** The addition of KahlLoadOuts and integration of dynamic equipment fields maintains type safety and follows MongoDB best practices. Also applies to: 862-862, 1181-1181 --- `805-828`: **LGTM! Well-structured infested foundry schema with proper date handling.** The schema correctly integrates with the EquipmentSchema for LastConsumedSuit and properly handles date transformation. Consider removing the eslint-disable comment by properly typing the ret parameter: ```diff infestedFoundrySchema.set("toJSON", { - transform(_doc, ret, _options) { + transform(_doc, ret: IInfestedFoundryDatabase, _options) { if (ret.AbilityOverrideUnlockCooldown) { - // eslint-disable-next-line @typescript-eslint/no-unsafe-argument ret.AbilityOverrideUnlockCooldown = toMongoDate(ret.AbilityOverrideUnlockCooldown); } } }); ``` </details> </blockquote></details> </details>

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: OpenWF/SpaceNinjaServer#867