fix: export common shared for external usage #756
Conversation
📝 WalkthroughWalkthroughConvert many model/supporting modules from default to named exports, rename WorldstateObject → WorldStateObject, add barrels and TS path aliases, adjust imports/usages across WorldState, tests, and tooling config; update formatter rules and lint/test scripts. Changes
Sequence Diagram(s)(Skipped — changes are refactor/type/export-oriented and do not introduce new multi-component sequential flows.) Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ 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. Comment |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (12)
lib/models/Mission.ts (1)
9-10: Consider using path alias for consistency.The import for
Dependencyuses a relative path ('./../supporting/Dependency') while the broader PR introduces path aliases like@/supporting. For consistency with the project-wide refactor, consider using the alias.🔎 Suggested change
-import type { Dependency } from './../supporting/Dependency'; +import type { Dependency } from '@/supporting';lib/models/Kuva.ts (1)
6-6: Consider simplifying the import path.The path
./../supporting/Dependencycan be simplified to../supporting/Dependency. Both are equivalent, but the latter is more conventional.🔎 Suggested change
-import type { Dependency } from './../supporting/Dependency'; +import type { Dependency } from '../supporting/Dependency';lib/models/Tmp.ts (1)
1-1: Consider simplifying the import path.Same as in
Kuva.ts, the path./../supporting/Dependencycan be simplified to../supporting/Dependency.🔎 Suggested change
-import type { Dependency } from './../supporting/Dependency'; +import type { Dependency } from '../supporting/Dependency';lib/models/Reward.ts (2)
3-3: Unconventional relative path.The path
./../supporting/Dependencyworks but is unconventional. Consider using../supporting/Dependencyfor consistency with standard relative import conventions.🔎 Suggested fix
-import type { Dependency } from './../supporting/Dependency'; +import type { Dependency } from '../supporting/Dependency';
82-88: Consider cachinggetTypesFull()result.
getTypesFull()is called twice forthumbnailand twice forcolor. While not a blocking issue, caching the result would avoid redundant computation.🔎 Suggested optimization
+ const typesFull = this.getTypesFull(); - this.thumbnail = this.getTypesFull()[0] - ? this.getTypesFull()[0].thumbnail + this.thumbnail = typesFull[0] + ? typesFull[0].thumbnail : 'https://i.imgur.com/JCKyUXJ.png'; - this.color = this.getTypesFull()[0] - ? this.getTypesFull()[0].color + this.color = typesFull[0] + ? typesFull[0].color : 0xf1c40f;lib/models/ChallengeInstance.ts (1)
3-3: Unconventional relative path.Same as in
Reward.ts, consider using../supporting/Dependencyinstead of./../supporting/Dependency.🔎 Suggested fix
-import type { Dependency } from './../supporting/Dependency'; +import type { Dependency } from '../supporting/Dependency';lib/models/SortieVariant.ts (1)
9-9: Consider simplifying the import path.The path
./../supporting/Dependencyis valid but unconventional. Consider using../supporting/Dependencyfor consistency with standard relative path conventions, or use the@/supportingalias if available.🔎 Suggested fix
-import type { Dependency } from './../supporting/Dependency'; +import type { Dependency } from '../supporting/Dependency';lib/supporting/DuviriChoice.ts (1)
17-23: Consider adding a default case for defensive coding.The switch statement handles
'EXC_NORMAL'and'EXC_HARD', but ifdata.Categoryhas an unexpected value at runtime (despite the type definition),this.categorywould remainundefined. While TypeScript's type narrowing should prevent this at compile time, a default case would provide runtime safety.🔎 Suggested fix
switch (data.Category) { case 'EXC_NORMAL': this.category = 'normal'; break; case 'EXC_HARD': this.category = 'hard'; + break; + default: + this.category = 'unknown'; }lib/models/WeeklyChallenge.ts (1)
11-15: Pre-existing JSDoc inaccuracy.The class description says "Represents a void trader" but this is the
WeeklyChallengeclass. This appears to be a copy-paste artifact from before this PR. Consider fixing while you're updating the file.🔎 Suggested JSDoc fix
/** - * Represents a void trader + * Represents a weekly challenge * @augments {WorldStateObject} */ export class WeeklyChallenge extends WorldStateObject {lib/models/PersistentEnemy.ts (1)
90-93: Inconsistent parameter type compared to other models.This constructor uses
{ locale: Locale }as the type annotation, while other models in this PR (e.g.,DailyDeal,SyndicateMission,GlobalUpgrade) use theDependencytype. For consistency across the codebase and to allow passing additional dependency fields if needed in the future, consider aligning with theDependencytype pattern:constructor( data: RawPersistentEnemy, - { locale }: { locale: Locale } = { locale: 'en' } + { locale = 'en' }: Dependency = { locale: 'en' } ) {Alternatively, if the narrower type is intentional, this is functionally correct.
lib/models/Nightwave.ts (1)
63-66: Same type inconsistency as PersistentEnemy.Uses
{ locale: Locale }instead ofDependency. Same observation as noted forPersistentEnemy.ts- consider aligning with theDependencytype for consistency if desired.lib/models/Fissure.ts (1)
116-118: Redundant date parsing.The base class
WorldStateObjectalready parsesActivationandExpiryin its constructor (seeWorldStateObject.tslines 47-55). These re-assignments are redundant sincesuper(data)is called first.If intentional for explicitness, this is harmless. Otherwise, these lines can be removed:
- this.activation = parseDate(data.Activation); - - this.expiry = parseDate(data.Expiry);
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (90)
biome.jsonlib/WorldState.tslib/models/Alert.tslib/models/Archimedea.tslib/models/Calendar.tslib/models/CambionCycle.tslib/models/CetusCycle.tslib/models/ChallengeInstance.tslib/models/ConclaveChallenge.tslib/models/ConstructionProgress.tslib/models/DailyDeal.tslib/models/DarkSector.tslib/models/DarkSectorBattle.tslib/models/DuviriCycle.tslib/models/EarthCycle.tslib/models/Fissure.tslib/models/FlashSale.tslib/models/GlobalUpgrade.tslib/models/Invasion.tslib/models/Kinepage.tslib/models/Kuva.tslib/models/MidrathCycle.tslib/models/Mission.tslib/models/News.tslib/models/Nightwave.tslib/models/NightwaveChallenge.tslib/models/PersistentEnemy.tslib/models/Reward.tslib/models/SentientOutpost.tslib/models/Simaris.tslib/models/Sortie.tslib/models/SortieVariant.tslib/models/SteelPathOffering.tslib/models/SyndicateJob.tslib/models/SyndicateMission.tslib/models/Tmp.tslib/models/VallisCycle.tslib/models/VoidTrader.tslib/models/VoidTraderItem.tslib/models/VoidTraderSchedule.tslib/models/WeeklyChallenge.tslib/models/WorldEvent.tslib/models/WorldStateObject.tslib/models/ZarimanCycle.tslib/models/index.tslib/supporting/Dependency.tslib/supporting/DuviriChoice.tslib/supporting/ExternalMission.tslib/supporting/FetchProxy.tslib/supporting/ImgCdn.tslib/supporting/KuvaLogEntry.tslib/supporting/RewardTypes.tslib/supporting/index.tsmain.tspackage.jsontest/integration/integration.spec.tstest/testclient.tstest/unit/alert.spec.tstest/unit/archimedea.spec.tstest/unit/calendar.spec.tstest/unit/cambion.spec.tstest/unit/cetus.spec.tstest/unit/conclavechallenge.spec.tstest/unit/construction.spec.tstest/unit/dailydeal.spec.tstest/unit/darksector.spec.tstest/unit/earth_cycle.spec.tstest/unit/event.spec.tstest/unit/fissure.spec.tstest/unit/flashsale.spec.tstest/unit/globalupgrade.spec.tstest/unit/invasion.spec.tstest/unit/kinepage.spec.tstest/unit/kuva.spec.tstest/unit/mission.spec.tstest/unit/news.spec.tstest/unit/nightwave.spec.tstest/unit/persistentenemy.spec.tstest/unit/reward.spec.tstest/unit/sentientOutpost.spec.tstest/unit/simaris.spec.tstest/unit/sortie.spec.tstest/unit/sortievariant.spec.tstest/unit/syndicatejob.spec.tstest/unit/syndicatemission.spec.tstest/unit/system.spec.tstest/unit/voidtrader.spec.tstest/unit/worldstate.spec.tstest/unit/zariman.spec.tstsconfig.json
🧰 Additional context used
🧠 Learnings (5)
📚 Learning: 2025-10-16T02:24:30.860Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 702
File: lib/models/Archidemea.ts:74-90
Timestamp: 2025-10-16T02:24:30.860Z
Learning: In Warframe's Archimedea/Conquest data structure (lib/models/Archidemea.ts), Digital Extremes duplicates difficulties when adding hard tier risks. The first risk in higher difficulties (e.g., CD_HARD) is always identical to the one in the normal difficulty (CD_NORMAL), so using `slice(1)` to skip the first risk when processing additional difficulties is the correct approach to avoid duplicates.
Applied to files:
lib/models/DarkSectorBattle.tslib/models/ChallengeInstance.tslib/models/Reward.tslib/models/SortieVariant.tstest/unit/archimedea.spec.tslib/WorldState.tslib/models/Archimedea.tslib/models/Mission.tslib/models/DarkSector.ts
📚 Learning: 2025-10-06T01:01:03.277Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 692
File: lib/Tmp.ts:49-51
Timestamp: 2025-10-06T01:01:03.277Z
Learning: In lib/Tmp.ts, the fields `QTCCFloofCount` and `QTCCFloofLimit` from the Warframe worldstate API always exist together - if one is present, the other is guaranteed to be present as well.
Applied to files:
lib/models/Tmp.ts
📚 Learning: 2024-12-19T17:07:27.023Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 593
File: lib/models/Calendar.js:31-45
Timestamp: 2024-12-19T17:07:27.023Z
Learning: In `Calendar.js`, the constructor can safely assume `calendar.Days` is always present and an array, per user statement.
Applied to files:
test/unit/calendar.spec.ts
📚 Learning: 2025-08-21T23:39:46.622Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 654
File: biome.json:43-50
Timestamp: 2025-08-21T23:39:46.622Z
Learning: Biome's import organization feature is configured using the "assist" → "actions" → "source" → "organizeImports" structure in biome.json, NOT as a top-level "organizeImports" section. The correct minimal configuration is:
```json
"assist": {
"enabled": true,
"actions": {
"source": {
"organizeImports": "on"
}
}
}
```
This is according to Biome's official documentation at https://biomejs.dev/assist/actions/organize-imports/
Applied to files:
biome.json
📚 Learning: 2025-08-21T23:39:46.622Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 654
File: biome.json:43-50
Timestamp: 2025-08-21T23:39:46.622Z
Learning: In Biome configuration (biome.json), import organization should be configured using the "assist" block with nested "actions" → "source" → "organizeImports" structure, not as a top-level "organizeImports" section. The correct format is:
```json
"assist": {
"enabled": true,
"actions": {
"source": {
"organizeImports": "on"
}
}
}
```
Applied to files:
biome.json
🧬 Code graph analysis (39)
lib/supporting/RewardTypes.ts (1)
lib/supporting/RewardData.ts (1)
auras(23-48)
test/unit/construction.spec.ts (1)
lib/models/ConstructionProgress.ts (1)
ConstructionProgress(9-30)
test/unit/kuva.spec.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/SentientOutpost.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/ChallengeInstance.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/DuviriCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/Reward.ts (2)
lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/supporting/RewardTypes.ts (1)
RewardType(8-33)
lib/models/WeeklyChallenge.ts (2)
lib/models/WorldStateObject.ts (2)
BaseContentObject(14-18)WorldStateObject(23-79)lib/models/ChallengeInstance.ts (2)
RawChallengeInstance(5-13)ChallengeInstance(18-69)
lib/models/MidrathCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/News.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/ImgCdn.ts (2)
deProxy(7-14)cdn(1-2)
lib/models/Calendar.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
test/unit/sentientOutpost.spec.ts (2)
lib/models/SentientOutpost.ts (1)
SentientOutpost(40-94)lib/supporting/Dependency.ts (1)
Dependency(9-39)
test/unit/reward.spec.ts (1)
lib/models/Reward.ts (1)
getItemType(9-12)
lib/models/Invasion.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/models/Reward.ts (1)
Reward(31-108)
lib/models/ZarimanCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/SyndicateJob.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/DailyDeal.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/GlobalUpgrade.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/Sortie.ts (3)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/SortieVariant.ts (1)
SortieVariant(21-76)
test/unit/syndicatejob.spec.ts (1)
lib/models/SyndicateJob.ts (2)
SyndicateJob(115-260)RawSyndicateJob(95-105)
lib/models/Alert.ts (4)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/Mission.ts (1)
Mission(40-230)lib/models/SentientOutpost.ts (1)
Mission(30-34)
lib/models/CetusCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/EarthCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/VallisCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
test/unit/archimedea.spec.ts (1)
lib/models/Archimedea.ts (2)
Archimedea(103-154)RawArchimedea(20-24)
lib/WorldState.ts (5)
lib/models/WorldStateObject.ts (2)
BaseContentObject(14-18)WorldStateObject(23-79)lib/models/SteelPathOffering.ts (1)
SteelPathOfferings(86-119)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/WorldEvent.ts (2)
WorldEvent(91-388)RawWorldEvent(46-85)lib/models/WeeklyChallenge.ts (1)
WeeklyChallenge(15-27)
lib/models/ConstructionProgress.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/Nightwave.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/SyndicateMission.ts (3)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/SyndicateJob.ts (1)
SyndicateJob(115-260)
lib/models/VoidTrader.ts (4)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/VoidTraderItem.ts (1)
VoidTraderItem(14-46)lib/models/VoidTraderSchedule.ts (1)
VoidTraderSchedule(9-20)
lib/models/PersistentEnemy.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/Archimedea.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/Mission.ts (2)
lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/Reward.ts (1)
Reward(31-108)
lib/models/NightwaveChallenge.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/FlashSale.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/CambionCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/DarkSector.ts (4)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/Mission.ts (1)
Mission(40-230)lib/models/DarkSectorBattle.ts (1)
DarkSectorBattle(22-79)
lib/models/Fissure.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/WorldEvent.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
🪛 GitHub Check: CodeQL
lib/models/SyndicateJob.ts
[failure] 229-229: Polynomial regular expression used on uncontrolled data
This regular expression that depends on library input may run slow on strings with many repetitions of 'A'.
This regular expression that depends on library input may run slow on strings with many repetitions of 'A'.
This regular expression that depends on library input may run slow on strings with many repetitions of 'A'.
This regular expression that depends on library input may run slow on strings with many repetitions of 'A'.
This regular expression that depends on library input may run slow on strings with many repetitions of 'A'.
This regular expression that depends on library input may run slow on strings with many repetitions of 'A'.
This regular expression that depends on library input may run slow on strings with many repetitions of 'A'.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Test (20)
- GitHub Check: Coverage
🔇 Additional comments (131)
test/unit/zariman.spec.ts (1)
3-3: LGTM!The import correctly uses the new path alias
@/modelswith a named import, aligning with the project-wide migration from default exports to named exports and centralized barrel files.lib/supporting/FetchProxy.ts (1)
10-22: LGTM!The reformatted function signature improves readability. The default values are correctly duplicated in both the destructuring assignment and the default object, ensuring proper defaults when the options object is partially provided or omitted entirely.
lib/supporting/ExternalMission.ts (1)
4-4: LGTM!The switch from default export to named export aligns with the project-wide refactor and enables cleaner imports via the barrel file pattern.
lib/supporting/RewardTypes.ts (1)
39-39: LGTM!The parentheses around the type assertion improve clarity and are consistent with biome formatting rules.
lib/supporting/ImgCdn.ts (1)
1-14: LGTM!Formatting changes only - the multi-line formatting improves readability without altering behavior.
lib/models/SteelPathOffering.ts (1)
86-93: LGTM!Good changes:
- Switch to named export aligns with the project-wide refactor
- Explicit public property declarations (
remaining,rotation,evergreens,incursions) improve API discoverability and type documentationlib/models/Mission.ts (1)
40-40: LGTM!The switch to named export aligns with the project-wide refactor and enables cleaner imports via the barrel file pattern.
package.json (1)
41-42: Good improvement: Usingbiome checkfor comprehensive verification.Switching from
biome linttobiome checkruns the full toolchain (formatting, linting, import-sorting) in a single command, which is the recommended approach for CI and local validation.lib/models/VoidTraderItem.ts (1)
3-3: LGTM! Consistent conversion to named exports.The changes correctly convert both the
Dependencyimport and theVoidTraderItemclass export from default to named style, aligning with the PR's objective to standardize on named exports across the codebase.Also applies to: 14-14
test/unit/darksector.spec.ts (1)
3-3: LGTM! Proper use of path alias and named imports.The import correctly uses the
@/modelsbarrel export to access bothDarkSectorand its type definition.test/testclient.ts (1)
1-2: LGTM! Improved test client clarity.The explicit
process.exit()calls on success (line 14) and error (line 17) make the test client's behavior more explicit and predictable. The updated import paths to.mjsextensions correctly target the compiled output.Also applies to: 14-17
test/unit/earth_cycle.spec.ts (1)
3-3: LGTM! Consistent path alias adoption.The import correctly uses the
@/modelsbarrel export with named import syntax, aligning with the PR's refactoring objectives.test/unit/flashsale.spec.ts (1)
3-3: LGTM! Proper path alias usage.The import correctly uses the
@/modelsbarrel export to access both the class and type definition.lib/models/DarkSectorBattle.ts (1)
6-6: Capitalization change has been consistently applied throughout the codebase.Verification confirms no remaining references to the old "WorldstateObject" spelling exist, and all imports and usages correctly reference "WorldStateObject" across the entire codebase. The change is complete and consistent.
test/unit/sortievariant.spec.ts (1)
3-6: The .js extension usage pattern is consistent across the codebase and intentional for ESM compatibility.All direct file imports from alias paths (e.g.,
@/models/SortieVariant.js,@/supporting/Dependency.js) use explicit.jsextensions, while barrel/directory imports (e.g.,@/models,@/supporting) omit the extension. This distinction is correctly applied throughout the codebase.main.ts (1)
5-6: Wildcard re-exports are appropriately scoped.The expanded public API from
./lib/supportingand./lib/modelsis properly structured. The exports consist entirely of intentional public-facing classes and interfaces (e.g.,Tmp,Alert,Mission,ImgCdn), and no internal or private APIs are unintentionally exposed. No naming conflicts arise from these wildcard exports, as all exported names are distinct across modules.test/unit/news.spec.ts (2)
3-6: LGTM! Clean migration to path aliases.The import updates correctly leverage the new path alias system for both models and test data, improving maintainability and reducing brittleness from relative paths.
94-95: Formatting change looks fine.The ImageUrl value split across lines is cosmetic and doesn't affect functionality.
test/unit/mission.spec.ts (1)
3-4: LGTM! Consistent with the alias migration.Import paths correctly updated to use the centralized alias system.
test/unit/globalupgrade.spec.ts (1)
3-3: LGTM! Import path updated correctly.test/unit/simaris.spec.ts (1)
3-3: LGTM! Import migration completed correctly.test/unit/sortie.spec.ts (1)
3-3: LGTM! Alias import applied correctly.lib/supporting/Dependency.ts (1)
9-9: Export style change from default to named export is complete and verified.All 16+ consumers of the
Dependencyinterface have been updated to use named imports (import type { Dependency }). No default imports remain in the codebase, and the re-export inlib/supporting/index.tsproperly exposes the named export.test/unit/worldstate.spec.ts (1)
5-11: Import paths updated correctly.The migration to path aliases is consistent. Note that Line 11 includes the
.jsextension in the alias path (@/WorldState.js), which differs from the extension-less imports used elsewhere. Verify this is intentional and supported by your module resolution strategy.tsconfig.json (1)
14-22: Path alias configuration is properly supported by build and test tooling.The baseUrl and paths configuration in tsconfig.json is correct. Verification confirms that path aliases are fully functional at runtime:
- Test execution: mocha is configured with the tsx loader (via
node-option: import=tsx), which natively supports TypeScript path aliases- Build output: tsdown, a TypeScript-based bundler, inherently supports all TypeScript features including path aliases—the dist directory and compiled output confirm successful builds
- Active usage: All three aliases (@/models, @/supporting, @/data) are actively used in source files (lib/) and test files, indicating the configuration works as intended
No additional build tool configuration is required.
lib/supporting/index.ts (1)
1-8: LGTM! Clean barrel export pattern.The barrel file correctly consolidates all supporting module exports, enabling cleaner imports throughout the codebase.
test/unit/kinepage.spec.ts (1)
4-4: LGTM! Alias-based import.The switch to path aliases improves maintainability and aligns with the project's new import strategy.
test/unit/calendar.spec.ts (2)
4-5: LGTM! Consistent alias usage.The import paths now use the project's path aliases, improving code organization and making imports more maintainable.
16-22: Multi-line formatting applied.The test assertions have been reformatted to multi-line style, which improves readability for longer assertion chains.
lib/models/VoidTraderSchedule.ts (2)
1-8: LGTM! Clean import and export refactoring.The conversion to named exports and type-only imports aligns with the project's new export strategy while preserving all functionality.
9-20: Named export applied consistently.The class is now exported as a named export, maintaining the same public interface and behavior.
test/unit/dailydeal.spec.ts (1)
3-3: LGTM! Consistent barrel import usage.The import correctly uses the barrel export from
@/models, providing a clean and maintainable import path.lib/models/Simaris.ts (2)
3-3: LGTM! Type-only import for Dependency.The import correctly uses a named type import since Dependency is only used in type positions.
13-48: Named export applied consistently.The class export has been converted to a named export, maintaining the same public interface (target, isTargetActive, asString) and behavior.
test/unit/cetus.spec.ts (1)
3-3: LGTM! Alias-based import.The import correctly uses the path alias and barrel export, providing a clean and maintainable import path.
test/unit/syndicatejob.spec.ts (1)
3-14: The direct module import pattern is consistent with other related tests.The
syndicatejob.spec.tsfile imports directly from@/models/SyndicateJob.jsrather than the barrel export. While this differs from the majority of test files (~83%), this same pattern is shared byVoidTrader.js,SyndicateMission.js, andSortieVariant.jsimports in their respective test files, suggesting this may be intentional for related modules.test/unit/nightwave.spec.ts (1)
3-5: LGTM! Import paths correctly updated to use path aliases.The migration to
@/models,@/supporting, and@/dataaliases is consistent with the PR's objective to establish centralized path aliases across the codebase.lib/models/WorldStateObject.ts (1)
23-23: Good rename toWorldStateObjectfor consistent PascalCase.The capitalization fix from
WorldstateObjecttoWorldStateObjectimproves naming consistency across the codebase. The switch to a named export aligns with the PR's broader refactoring objective.test/unit/reward.spec.ts (1)
5-5: LGTM! Import correctly updated to use named exports from the barrel module.The import of
getItemType,RawReward, andRewardas named exports from@/modelsaligns with the public API changes inlib/models/Reward.ts.lib/models/Kinepage.ts (2)
1-1: LGTM! Named export aligns with the codebase-wide refactoring.
20-27: Improved readability with multi-line formatting.The translation extraction logic is now more readable with clearer line breaks for the
Object.fromEntriescalls.test/unit/event.spec.ts (1)
3-4: LGTM! Imports correctly updated to use path aliases and renamed class.lib/models/Kuva.ts (1)
92-92: LGTM! Named export aligns with the codebase-wide refactoring.lib/models/Tmp.ts (1)
1-3: LGTM! Named imports correctly updated to match export changes.The imports for
KinepageandSentientOutpostas named exports align with their respective module changes. Based on retrieved learnings, the non-null assertion onQTCCFloofLimit(line 38) is valid since these fields always exist together in the API response.test/unit/construction.spec.ts (2)
3-3: LGTM!The import correctly uses the new path alias and named export pattern. The class reference is now consistent with the actual class name
ConstructionProgress.
13-29: Test updates align with the refactored export.All instantiations correctly reference
ConstructionProgressinstead of the previous alias. Test assertions remain unchanged and continue to validate the expected behavior.lib/models/Reward.ts (1)
31-31: Named export aligns with PR objectives.The switch from default to named export is consistent with the codebase-wide refactoring.
lib/models/Invasion.ts (3)
9-12: Clean import refactoring.Imports correctly use the barrel export from
../supportingand named imports for local modules. This aligns well with the centralized export pattern.
50-50: Named export with updated base class.The switch to named export and
WorldStateObject(corrected capitalization) is consistent with the PR objectives.
126-139: Reward instantiation logic is sound.The optional chaining and empty object check correctly handle cases where attacker/defender rewards may be absent.
lib/models/ChallengeInstance.ts (1)
18-68: Named export and formatting changes look good.The class export and constructor formatting align with the PR's refactoring pattern. Logic remains unchanged.
test/unit/alert.spec.ts (1)
3-4: Path alias imports look good.The imports correctly use the new
@/modelsand@/datapath aliases. The JSON import attribute syntax (with { type: 'json' }) follows modern ESM conventions for importing JSON modules.test/unit/archimedea.spec.ts (2)
4-5: Path alias imports correctly applied.The imports use the new
@/modelsand@/datapath aliases with proper named export syntax.
13-22: Class name corrected toArchimedea.All references updated from
ArchidemeatoArchimedea, fixing the typo in the class name. Test logic remains intact.lib/models/CetusCycle.ts (3)
2-3: Import updated to named import.The import correctly uses the named export pattern for
WorldStateObject.
23-25: JSDoc and export updated correctly.The
@augmentstag and class declaration both referenceWorldStateObjectwith corrected capitalization, and the class is now a named export.
103-110: Formatting changes only.The calculation logic is unchanged; only line breaks were adjusted for readability.
lib/models/DuviriCycle.ts (2)
2-2: Import updated to named import.The import correctly uses the named export pattern for
WorldStateObject.
32-35: JSDoc and class declaration updated.The
@typedef,@augments, and class declaration all correctly referenceWorldStateObjectwith proper capitalization. The switch to a named export aligns with the PR objectives.test/unit/persistentenemy.spec.ts (1)
3-3: LGTM!The import correctly uses the named export syntax with the new
@/modelspath alias, aligning with the PR-wide refactoring.lib/supporting/KuvaLogEntry.ts (1)
1-19: LGTM!Formatting changes are consistent and appear to be formatter-driven. No functional changes to the interface definitions.
test/integration/integration.spec.ts (3)
9-9: LGTM!The import correctly uses the path alias for the FetchProxy module.
39-43: LGTM!The expanded options object improves readability, and explicitly passing
kuvaData: undefinedaligns with the commented-out kuva data fetching above.
55-66: LGTM!Multi-line formatting for the filter and assertion chains improves readability without changing behavior.
lib/models/NightwaveChallenge.ts (3)
7-7: LGTM!The import correctly uses named import syntax for
WorldStateObjectandBaseContentObject, aligning with the PR-wide refactoring.
19-21: LGTM!The JSDoc
@augmentsannotation and class declaration correctly reference the renamedWorldStateObjectbase class.
57-60: LGTM!Multi-line constructor signature improves readability without changing behavior.
lib/models/VallisCycle.ts (3)
3-3: LGTM!The import correctly uses named import syntax for
WorldStateObject.
67-69: LGTM!The JSDoc
@augmentsannotation and class declaration correctly reference the renamedWorldStateObjectbase class, and the class is now exported as a named export.
37-38: Pre-existing issue: Possible bug in cycle calculation.Line 38 uses
lStart.getMilliseconds()which returns only the milliseconds component (0-999), not the full timestamp. This seems like it should belStart.getTime()to get the epoch timestamp for the cycle calculation. This is not part of the current PR's changes but may be worth investigating.test/unit/sentientOutpost.spec.ts (2)
4-5: LGTM!The imports correctly use named exports with path aliases. Using
typeimport forDependencyis appropriate since it's only used for type casting.
13-16: LGTM!Multi-line formatting for the constructor call improves readability without changing test behavior.
test/unit/conclavechallenge.spec.ts (1)
3-6: LGTM!The imports correctly use named exports with path aliases. The JSON import attribute (
with { type: 'json' }) is the proper ESM syntax for importing JSON modules.lib/models/SentientOutpost.ts (3)
1-7: LGTM!The imports are correctly organized with multi-line formatting, and using
typeimport forDependencyis appropriate since it's only used for type annotations.
40-62: LGTM!The class is now a named export with explicitly declared public properties (
id,activation,expiry,mission,active), improving the public API surface and TypeScript type inference.
68-71: LGTM!Multi-line constructor signature improves readability. The destructuring of
Dependencyis correct.test/unit/invasion.spec.ts (1)
3-3: LGTM!The import correctly uses the new
@/modelspath alias with named exports, aligning with the PR's refactoring goals. Thetypemodifier onRawInvasionis appropriate for type-only imports.lib/models/ZarimanCycle.ts (1)
3-3: LGTM!The import and export changes correctly follow the PR's refactoring pattern:
- Named import of
WorldStateObject(with corrected capitalization)- Named export of the class
- JSDoc
@augmentsupdated to match the renamed base classAlso applies to: 23-25
test/unit/cambion.spec.ts (1)
3-3: LGTM!The import correctly uses named exports from the
@/modelsalias. Usingtype CetusCycleis appropriate since it's only used for type assertions in the tests.lib/models/SortieVariant.ts (1)
21-21: LGTM!The class is correctly converted to a named export, and the constructor reformatting improves readability.
Also applies to: 58-61
lib/models/ConstructionProgress.ts (2)
10-12: LGTM!The new
unknownProgressproperty extends the public API surface appropriately. The property declarations align with the existing pattern forfomorianProgressandrazorbackProgress.
3-3: LGTM!The import and export changes correctly follow the PR's refactoring pattern with named imports/exports and the updated
WorldStateObjectbase class.Also applies to: 9-9
lib/models/EarthCycle.ts (1)
3-3: LGTM!The import and export changes correctly follow the PR's refactoring pattern:
- Named import of
WorldStateObject- Named export of
EarthCycle- JSDoc
@augmentsupdated to reflect the renamed base classAlso applies to: 84-86
lib/supporting/DuviriChoice.ts (1)
1-1: LGTM!The import correctly uses the barrel export from
../modelsfor type imports, and the class is properly converted to a named export.Also applies to: 11-11
test/unit/fissure.spec.ts (1)
3-3: LGTM!The import correctly uses the
@/modelspath alias with named exports, consistent with the PR's refactoring pattern across all test files.test/unit/system.spec.ts (1)
3-8: LGTM – Import aliases and named exports correctly applied.The switch to path aliases (
@/supporting,@/data,@/../main.js) and the named export forDependencyaligns with the broader PR refactoring. The imports are well-organized with appropriate grouping.lib/models/SyndicateJob.ts (2)
3-5: LGTM – Named exports and type imports properly updated.Import changes correctly use named exports for
Dependency(as type import) andWorldStateObject/Identifier, aligning with the codebase-wide refactor.
115-115: LGTM – Named export with updated base class.The switch from default export to named export and the base class rename to
WorldStateObjectis consistent with the PR's public API surface changes.lib/models/MidrathCycle.ts (2)
5-5: LGTM – Named import for WorldStateObject.The import update aligns with the renamed and re-exported base class across the codebase.
45-45: LGTM – Named export with correct base class.The switch to named export and
WorldStateObjectbase class is consistent with the broader refactor.lib/models/ConclaveChallenge.ts (2)
10-12: LGTM – Import updates properly structured.The type import for
Dependencyand named imports forBaseContentObject/WorldStateObjectcorrectly follow the new public API surface pattern.
27-27: LGTM – Named export with WorldStateObject base.Consistent with the codebase-wide migration to named exports and the
WorldStateObjectcapitalization.test/unit/syndicatemission.spec.ts (1)
3-6: LGTM – Consolidated named imports from alias path.The switch to a single import statement with both the type (
RawSyndicateMission) and class (SyndicateMission) from the alias path@/models/SyndicateMission.jsis clean and aligns with the PR's refactoring goals.biome.json (2)
51-77: LGTM – Import organization correctly configured.The
assist.actions.source.organizeImportsstructure properly follows Biome's documented configuration format. The import groups logically organize:
- URL imports
- Node/Bun built-ins
- External packages
- Organization packages (
@wfcd/)- Project path aliases (
@/models,@/supporting,@/data)- Relative imports
Based on learnings, this matches the correct Biome configuration structure.
2-2: Schema version is valid and stable.Biome 2.3.10 is confirmed as a valid stable release.
lib/models/CambionCycle.ts (2)
3-4: LGTM – Named imports correctly applied.The type import for
CetusCycleand value import forWorldStateObjectproperly follow the new named export pattern.
10-10: LGTM – Named export with WorldStateObject base.Consistent with the codebase-wide migration to named exports and the
WorldStateObjectcapitalization.test/unit/kuva.spec.ts (1)
3-5: LGTM – Path aliases and named exports properly applied.The imports correctly use:
- Named export for
Kuvafrom the barrel module@/models- Type-only import for
Dependencyfrom@/supporting- JSON import with proper import attribute syntax
This aligns well with the PR's refactoring goals and modern ESM practices.
lib/models/Archimedea.ts (2)
1-13: LGTM! Import reorganization and named exports.The changes properly update imports to use the path alias
@/supportingfor the Dependency type and switch to named exports fromWorldStateObject. The formatting is clean and consistent with the PR objectives.
103-153: LGTM! Class export and formatting changes.The switch from default export to named export (
export class Archimedea) and the minor formatting adjustments in the constructor are clean. No behavioral changes.lib/models/Calendar.ts (2)
1-8: LGTM! Import updates.The imports are properly reorganized with the named import for
WorldStateObjectandBaseContentObjectfrom the local module path.
65-108: LGTM! Named export conversion.The switch to named export for
Calendarclass is consistent with the codebase-wide refactoring. Minor formatting adjustments are clean.lib/models/FlashSale.ts (2)
8-9: LGTM! Import updates.The imports are correctly updated to use type-only import for
Dependencyand named imports forWorldStateObjectandBaseContentObject.
26-76: LGTM! Named export and constructor formatting.The conversion to named export and the constructor signature formatting are clean. No behavioral changes.
lib/models/News.ts (3)
10-12: LGTM! Import updates.The blank line additions and named import for
WorldStateObjectproperly align with the codebase-wide refactoring.
33-35: LGTM! JSDoc and export updates.The
@augmentstag correctly referencesWorldStateObjectwith proper capitalization, and the class is now a named export.
90-145: LGTM! Constructor formatting.The multi-line formatting changes in the constructor improve readability without changing any behavior.
lib/models/Alert.ts (2)
3-6: LGTM! Import reorganization.Clean separation of type imports and value imports, properly using named exports from the updated module structure.
15-47: LGTM! Named export and constructor updates.The class is correctly converted to a named export. The use of optional chaining in
this.reward?.getTypes()?.lengthis appropriate defensive coding.lib/models/VoidTrader.ts (2)
9-13: LGTM! Import updates.The imports are properly organized with type-only import for
Dependencyand named imports for model classes and types.
26-91: LGTM! Named export and constructor formatting.The conversion to named export is correct. The use of nullish coalescing (
character ?? '') on line 79 provides a clean fallback. All formatting changes improve readability without altering behavior.lib/models/DarkSector.ts (3)
1-10: LGTM! Import reorganization.The imports are properly restructured with named exports from the updated module paths.
45-47: LGTM! Named export conversion.The JSDoc and class declaration are correctly updated for the named export pattern.
158-224: LGTM! Constructor formatting changes.The multi-line formatting changes improve readability. All conditional assignments (
parseDate,new Mission,map) retain their original logic.lib/models/WeeklyChallenge.ts (2)
1-5: LGTM! Import updates.The imports are properly organized with named exports for both
ChallengeInstanceandWorldStateObject.
21-26: LGTM! Constructor formatting.The multi-line formatting for the
mapcallback improves readability.lib/models/DailyDeal.ts (1)
8-9: LGTM - Consistent with PR-wide refactoring pattern.The changes correctly migrate to named exports and update the base class reference from
WorldstateObjecttoWorldStateObject. The import paths and constructor formatting are consistent with the other model files in this PR.Also applies to: 25-25, 71-74
lib/models/SyndicateMission.ts (1)
1-11: LGTM - Clean migration to named exports with barrel imports.The file correctly migrates to named exports and uses the cleaner barrel import pattern (
../supporting) for theDependencytype. The@augmentsannotation and class declaration are properly updated to referenceWorldStateObject.Also applies to: 22-22
lib/models/Sortie.ts (1)
10-14: LGTM - Properly aligned with the refactoring pattern.The imports, export style, and constructor parameter type (
Dependency) are consistent with the PR-wide conventions. The@augmentsannotation correctly referencesWorldStateObject.Also applies to: 27-29, 65-68
lib/models/GlobalUpgrade.ts (1)
10-11: LGTM - Consistent implementation.The migration to named exports, updated imports, and
Dependencytype usage are all properly aligned with the PR's refactoring conventions.Also applies to: 24-24, 50-53
lib/models/Fissure.ts (1)
13-15: LGTM - Core refactoring changes are correct.The migration to named exports, updated
@augmentsannotation, and constructor signature changes are properly implemented and consistent with the PR pattern.Also applies to: 29-31, 87-90
lib/WorldState.ts (4)
5-61: LGTM - Clean consolidation of imports using path aliases.The migration to the
@/modelsand@/supportingbarrel imports significantly improves import organization. All model types and their raw data types are now imported from a single source, which enhances maintainability.
119-122: Appropriate generic constraint update.The
T extends WorldStateObjectconstraint correctly reflects thatparseAsyncArrayoperates on classes withWorldStateObjectproperties (likeid,active). This aligns with the filtering logic on line 140 that accessesobj.active.
525-528: Clean spread pattern for adding character dependency.The explicit
character: 'Varzia'addition via spread is clear and maintainable.
336-336: Type correctly renamed fromSteelPathOfferingtoSteelPathOfferings. No remaining references to the singular type exist. The property type aligns with the actual class name, and all downstream usages are consistent.lib/models/WorldEvent.ts (5)
11-18: Imports updated to use named exports and path alias.The import changes correctly align with the codebase-wide refactor:
- Using named type imports for
Dependency,RawReward,RawSyndicateJob,BaseContentObject,Identifier- Importing
WorldStateObject(consistent capitalization) as the base class
232-235: LGTM!Multi-line formatting for the method signature improves readability.
260-263: LGTM!Constructor signature formatting is clean with appropriate default value handling for the
Dependencyparameter.
280-288: Formatting changes improve readability.Multi-line ternary expressions and callback formatting are consistent and align with the biome formatter rules.
89-91: Named export and base class extension are correct.The class properly uses a named export and extends
WorldStateObject. Verification confirms all imports in the codebase are using the named import pattern—no default imports ofWorldEventwere found. The barrel export inindex.tsmaintains compatibility with the import structure.lib/models/index.ts (1)
1-42: Well-structured barrel export file with complete model coverage.This provides a clean, centralized entry point for all model exports. The alphabetical ordering aids maintainability, and verification confirms all 42 model files in the directory are included with no duplicates.
One consideration: using
export *can inadvertently expose internal types. If any modules export implementation details that shouldn't be part of the public API, consider using explicit named re-exports for those modules.
TobiTenno
changed the title
TobiTenno
force-pushed
the
aliases-exports-oh-my
branch
from
fdce031 to
4062218
Compare
There was a problem hiding this comment.
Actionable comments posted: 7
♻️ Duplicate comments (4)
lib/models/Mission.ts (1)
9-9: Verify the import path syntax.Same issue as in SentientOutpost.ts: the import path
./@/supporting/Dependencycombines a relative path prefix with a path alias. Verify this is the intended format.lib/models/Sortie.ts (1)
11-11: Verify the import path syntax.Same pattern:
./@/supporting/Dependencycombines relative prefix with path alias.lib/models/Fissure.ts (1)
14-14: Verify the import path syntax.Same issue:
./@/supporting/Dependencycombines relative prefix with path alias.lib/models/WorldEvent.ts (1)
343-345: Note: Pre-existing issue remains unaddressed.As flagged in a previous review, the
MultiProgressreduce operation may have a string concatenation issue sinceMultiProgressis typed asstring[]. This formatting change doesn't address that concern.Since this PR focuses on refactoring exports and imports rather than fixing logic bugs, this issue can be addressed separately. However, it's worth keeping in mind for future work.
🧹 Nitpick comments (2)
lib/supporting/FetchProxy.ts (1)
10-22: Good: Named export aligns with the PR's goal of enabling external usage.The change from default to named export is appropriate. However, the default values are duplicated in both the destructuring pattern (lines 13-14) and the fallback object (lines 19-20). Consider simplifying by relying only on the destructuring defaults:
🔎 Suggested simplification
export const fetchProxy = async ( url: string, { session = 'parser-session', contentType = 'application/json', }: { session?: string; contentType?: 'application/json' | 'text/html'; - } = { - session: 'parser-session', - contentType: 'application/json', - } + } = {} ) => {lib/supporting/DuviriChoice.ts (1)
17-23: Consider adding a default case to the switch statement.The switch statement lacks a default case, which means
this.categorywill beundefinedifdata.Categoryhas an unexpected value at runtime. While TypeScript constrains the type, adding a default case improves defensive programming.🔎 Suggested enhancement
switch (data.Category) { case 'EXC_NORMAL': this.category = 'normal'; break; case 'EXC_HARD': this.category = 'hard'; + break; + default: + this.category = 'unknown'; }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (90)
biome.jsonlib/WorldState.tslib/models/Alert.tslib/models/Archimedea.tslib/models/Calendar.tslib/models/CambionCycle.tslib/models/CetusCycle.tslib/models/ChallengeInstance.tslib/models/ConclaveChallenge.tslib/models/ConstructionProgress.tslib/models/DailyDeal.tslib/models/DarkSector.tslib/models/DarkSectorBattle.tslib/models/DuviriCycle.tslib/models/EarthCycle.tslib/models/Fissure.tslib/models/FlashSale.tslib/models/GlobalUpgrade.tslib/models/Invasion.tslib/models/Kinepage.tslib/models/Kuva.tslib/models/MidrathCycle.tslib/models/Mission.tslib/models/News.tslib/models/Nightwave.tslib/models/NightwaveChallenge.tslib/models/PersistentEnemy.tslib/models/Reward.tslib/models/SentientOutpost.tslib/models/Simaris.tslib/models/Sortie.tslib/models/SortieVariant.tslib/models/SteelPathOffering.tslib/models/SyndicateJob.tslib/models/SyndicateMission.tslib/models/Tmp.tslib/models/VallisCycle.tslib/models/VoidTrader.tslib/models/VoidTraderItem.tslib/models/VoidTraderSchedule.tslib/models/WeeklyChallenge.tslib/models/WorldEvent.tslib/models/WorldStateObject.tslib/models/ZarimanCycle.tslib/models/index.tslib/supporting/Dependency.tslib/supporting/DuviriChoice.tslib/supporting/ExternalMission.tslib/supporting/FetchProxy.tslib/supporting/ImgCdn.tslib/supporting/KuvaLogEntry.tslib/supporting/RewardTypes.tslib/supporting/index.tsmain.tspackage.jsontest/integration/integration.spec.tstest/testclient.tstest/unit/alert.spec.tstest/unit/archimedea.spec.tstest/unit/calendar.spec.tstest/unit/cambion.spec.tstest/unit/cetus.spec.tstest/unit/conclavechallenge.spec.tstest/unit/construction.spec.tstest/unit/dailydeal.spec.tstest/unit/darksector.spec.tstest/unit/earth_cycle.spec.tstest/unit/event.spec.tstest/unit/fissure.spec.tstest/unit/flashsale.spec.tstest/unit/globalupgrade.spec.tstest/unit/invasion.spec.tstest/unit/kinepage.spec.tstest/unit/kuva.spec.tstest/unit/mission.spec.tstest/unit/news.spec.tstest/unit/nightwave.spec.tstest/unit/persistentenemy.spec.tstest/unit/reward.spec.tstest/unit/sentientOutpost.spec.tstest/unit/simaris.spec.tstest/unit/sortie.spec.tstest/unit/sortievariant.spec.tstest/unit/syndicatejob.spec.tstest/unit/syndicatemission.spec.tstest/unit/system.spec.tstest/unit/voidtrader.spec.tstest/unit/worldstate.spec.tstest/unit/zariman.spec.tstsconfig.json
✅ Files skipped from review due to trivial changes (1)
- lib/supporting/RewardTypes.ts
🚧 Files skipped from review as they are similar to previous changes (29)
- lib/supporting/ImgCdn.ts
- lib/models/Kinepage.ts
- test/unit/cetus.spec.ts
- test/unit/news.spec.ts
- test/unit/dailydeal.spec.ts
- test/unit/persistentenemy.spec.ts
- test/unit/syndicatemission.spec.ts
- test/unit/invasion.spec.ts
- test/unit/cambion.spec.ts
- lib/models/VallisCycle.ts
- lib/models/Tmp.ts
- test/unit/construction.spec.ts
- test/unit/conclavechallenge.spec.ts
- test/unit/reward.spec.ts
- package.json
- test/unit/fissure.spec.ts
- lib/models/MidrathCycle.ts
- lib/models/Alert.ts
- test/unit/event.spec.ts
- lib/models/DailyDeal.ts
- main.ts
- lib/models/DuviriCycle.ts
- test/unit/voidtrader.spec.ts
- test/unit/earth_cycle.spec.ts
- lib/models/VoidTraderItem.ts
- test/unit/zariman.spec.ts
- lib/models/Reward.ts
- test/unit/flashsale.spec.ts
- test/unit/alert.spec.ts
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-10-16T02:24:30.860Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 702
File: lib/models/Archidemea.ts:74-90
Timestamp: 2025-10-16T02:24:30.860Z
Learning: In Warframe's Archimedea/Conquest data structure (lib/models/Archidemea.ts), Digital Extremes duplicates difficulties when adding hard tier risks. The first risk in higher difficulties (e.g., CD_HARD) is always identical to the one in the normal difficulty (CD_NORMAL), so using `slice(1)` to skip the first risk when processing additional difficulties is the correct approach to avoid duplicates.
Applied to files:
lib/models/Archimedea.tslib/models/DarkSectorBattle.tslib/models/Mission.tslib/WorldState.tslib/models/DarkSector.tslib/models/SortieVariant.ts
📚 Learning: 2025-08-21T23:39:46.622Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 654
File: biome.json:43-50
Timestamp: 2025-08-21T23:39:46.622Z
Learning: Biome's import organization feature is configured using the "assist" → "actions" → "source" → "organizeImports" structure in biome.json, NOT as a top-level "organizeImports" section. The correct minimal configuration is:
```json
"assist": {
"enabled": true,
"actions": {
"source": {
"organizeImports": "on"
}
}
}
```
This is according to Biome's official documentation at https://biomejs.dev/assist/actions/organize-imports/
Applied to files:
biome.json
📚 Learning: 2025-08-21T23:39:46.622Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 654
File: biome.json:43-50
Timestamp: 2025-08-21T23:39:46.622Z
Learning: In Biome configuration (biome.json), import organization should be configured using the "assist" block with nested "actions" → "source" → "organizeImports" structure, not as a top-level "organizeImports" section. The correct format is:
```json
"assist": {
"enabled": true,
"actions": {
"source": {
"organizeImports": "on"
}
}
}
```
Applied to files:
biome.json
📚 Learning: 2024-12-19T17:07:27.023Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 593
File: lib/models/Calendar.js:31-45
Timestamp: 2024-12-19T17:07:27.023Z
Learning: In `Calendar.js`, the constructor can safely assume `calendar.Days` is always present and an array, per user statement.
Applied to files:
test/unit/calendar.spec.tslib/models/Calendar.ts
🧬 Code graph analysis (31)
lib/models/Archimedea.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
test/unit/syndicatejob.spec.ts (1)
lib/models/SyndicateJob.ts (2)
SyndicateJob(115-262)RawSyndicateJob(95-105)
lib/models/CetusCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/ChallengeInstance.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/Nightwave.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/SyndicateJob.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/SentientOutpost.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/Kuva.ts (1)
lib/supporting/ExternalMission.ts (1)
ExternalMission(4-56)
lib/models/SyndicateMission.ts (3)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/SyndicateJob.ts (1)
SyndicateJob(115-262)
test/unit/sentientOutpost.spec.ts (2)
lib/models/SentientOutpost.ts (1)
SentientOutpost(40-94)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/CambionCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/Fissure.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
test/unit/kuva.spec.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/EarthCycle.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
test/unit/archimedea.spec.ts (1)
lib/models/Archimedea.ts (2)
Archimedea(103-154)RawArchimedea(20-24)
lib/models/NightwaveChallenge.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/GlobalUpgrade.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/FlashSale.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/Mission.ts (2)
lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/Reward.ts (1)
Reward(32-109)
lib/models/Calendar.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/ConclaveChallenge.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/Sortie.ts (3)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/SortieVariant.ts (1)
SortieVariant(21-76)
lib/WorldState.ts (6)
lib/models/WorldStateObject.ts (2)
BaseContentObject(14-18)WorldStateObject(23-79)lib/models/SteelPathOffering.ts (1)
SteelPathOfferings(86-119)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/WorldEvent.ts (2)
WorldEvent(92-389)RawWorldEvent(47-86)lib/models/SyndicateMission.ts (2)
SyndicateMission(23-96)RawSyndicateMission(13-17)lib/models/WeeklyChallenge.ts (1)
WeeklyChallenge(15-27)
lib/models/DarkSector.ts (4)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/Mission.ts (1)
Mission(40-230)lib/models/DarkSectorBattle.ts (1)
DarkSectorBattle(22-79)
lib/models/VoidTrader.ts (4)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/VoidTraderItem.ts (1)
VoidTraderItem(14-46)lib/models/VoidTraderSchedule.ts (1)
VoidTraderSchedule(9-20)
lib/models/Invasion.ts (3)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/Reward.ts (1)
Reward(32-109)
lib/models/WorldEvent.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/News.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/ImgCdn.ts (2)
deProxy(7-14)cdn(1-2)
lib/models/SortieVariant.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/ConstructionProgress.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
lib/models/PersistentEnemy.ts (1)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test (20)
🔇 Additional comments (81)
lib/models/DarkSectorBattle.ts (1)
1-79: LGTM! Clean refactor to named export.The conversion from default export to named export is consistent with the PR's objective to standardize the public API surface. The import of
IdentifierfromWorldStateObjectcorrectly reflects the renamed base class, and the class logic remains intact.lib/supporting/Dependency.ts (1)
9-39: LGTM! Dependency interface converted to named export.The change from default export to named export aligns with the PR's goal of standardizing the public API. The interface definition remains unchanged, preserving all existing functionality.
lib/models/ChallengeInstance.ts (1)
18-68: LGTM! Clean refactor to named export with improved formatting.The conversion to named export is consistent with PR objectives. The constructor parameter formatting improvements enhance readability without altering functionality.
test/unit/nightwave.spec.ts (2)
3-5: LGTM! Test imports updated to use path aliases.The imports correctly use the new path aliases (
@/models,@/supporting,@/data) and named exports, aligning with the PR's refactoring objectives.
35-35: Minor formatting improvement.Added semicolon for consistency.
test/unit/sortievariant.spec.ts (1)
3-3: LGTM! Test imports updated to use path aliases.The import correctly uses the
@/modelspath alias and named exports for bothSortieVariantandRawSortieVariant, aligning with the PR's refactoring objectives.lib/models/SortieVariant.ts (2)
1-9: LGTM! Import formatting improved.The multi-line import formatting from
warframe-worldstate-data/utilitiesenhances readability. The Dependency import uses the@/supporting/Dependencyalias correctly.
21-76: LGTM! Clean refactor to named export.The conversion from default export to named export is consistent with the PR's objective. Constructor parameter formatting improvements enhance readability without changing functionality.
lib/supporting/KuvaLogEntry.ts (1)
1-19: LGTM! Formatting consistency improvements.The changes add semicolons and normalize spacing in the interface definitions, improving code style consistency without altering functionality.
lib/models/SteelPathOffering.ts (2)
3-6: LGTM! Import formatting improved.Multi-line import formatting enhances readability.
86-118: LGTM! Well-structured class with clear initialization logic.The conversion to a named export (
SteelPathOfferings) is consistent with PR objectives. The class aggregatesSteelPathOfferingitems from the external data package and provides a clean interface for steel path rotation data. The constructor logic for calculating the current rotation index and time windows is sound.biome.json (1)
51-77: LGTM! Import organization configuration follows the correct Biome structure.The nested
assist.actions.source.organizeImportsstructure is correct per Biome's documentation. The import groups properly reflect the path aliases (@/models,@/supporting,@/data) introduced in this PR. Based on learnings, this is the proper way to configure import organization in Biome.lib/models/NightwaveChallenge.ts (1)
7-21: LGTM! Named export and WorldStateObject base class are correctly applied.The changes align with the PR's goal of exporting types for external usage:
- Import updated to use named
WorldStateObjectexport- JSDoc
@augmentsannotation updated to match the renamed class- Class now uses named export pattern
lib/models/PersistentEnemy.ts (1)
10-29: LGTM! Consistent with the PR's export refactoring pattern.The changes properly:
- Import
WorldStateObjectandBaseContentObjectas named exports- Update the
@augmentsJSDoc to reference the renamed base class- Convert to named class export
This is consistent with other model files in this PR.
lib/WorldState.ts (3)
6-61: LGTM! Consolidated barrel imports improve maintainability.The refactoring from individual model imports to a consolidated
@/modelsbarrel import is clean and aligns with the PR's goal of exposing a unified public API. The@/supportingimports are similarly well-structured.
394-402: Good: Explicit generic parameters improve type inference.Adding explicit type parameters
<WorldEvent, RawWorldEvent>and<SyndicateMission, RawSyndicateMission>to theparseAsyncArraycalls improves code clarity and ensures proper type inference.
336-336: TheSteelPathOfferingstype is correct and matches the exported class name.The exported class from
lib/models/SteelPathOffering.tsisSteelPathOfferings(plural), and the type annotation at line 336 correctly usesSteelPathOfferings.test/unit/simaris.spec.ts (1)
3-3: LGTM! Test import updated to use the new named export and path alias.The change from
import Simaris from '../../lib/models/Simaris.js'toimport { Simaris } from '@/models'correctly reflects:
- The model's conversion to a named export
- The project's adoption of path aliases
test/unit/mission.spec.ts (1)
3-4: LGTM! Test imports correctly use path aliases for both models and data.The imports are updated to:
- Use named export
{ Mission, type RawMission }from@/models- Use the
@/dataalias for test data with proper JSON import attributesThis is consistent with other test file updates in the PR.
lib/models/EarthCycle.ts (3)
3-3: LGTM! Import updated for WorldStateObject rename.The import correctly reflects the renamed base class and the shift to named exports.
56-58: LGTM! Multi-line formatting for readability.The calculation logic remains unchanged; the reformatting improves readability.
84-86: LGTM! Class export and documentation updated.The changes correctly:
- Update JSDoc to reference WorldStateObject
- Change from default export to named export
- Extend the renamed WorldStateObject class
These align with the PR's public API surface refactor.
test/unit/calendar.spec.ts (2)
4-5: LGTM! Imports updated to use path aliases.The imports correctly use the configured path aliases (
@/modelsand@/data) and reflect the shift to named exports for Calendar.
16-22: LGTM! Multi-line formatting for readability.The test assertions remain semantically identical; the formatting improves readability.
test/unit/worldstate.spec.ts (1)
5-7: LGTM! Imports updated to use path aliases.The imports correctly use the configured path aliases and reflect the WorldStateObject rename and shift to named exports.
test/unit/sortie.spec.ts (1)
3-3: LGTM! Import updated to use path alias.The import correctly uses the configured
@/modelsalias and reflects the shift to named exports.test/testclient.ts (3)
1-2: LGTM! Import paths updated to .mjs variants.The imports correctly point to the compiled .mjs files in the dist directory.
5-10: LGTM! Multi-line formatting for fetch calls.The reformatting improves readability without changing the fetch logic.
14-17: LGTM! Explicit process exit codes added.Adding explicit exit codes is good practice for test clients, ensuring proper termination status reporting.
lib/supporting/ExternalMission.ts (1)
4-4: LGTM! Interface export updated to named export.The change from default export to named export aligns with the PR's goal to improve the public API surface and enable better tree-shaking.
lib/models/WorldStateObject.ts (3)
1-7: LGTM! Multi-line import formatting.The reformatting improves readability and clearly lists all imported utilities.
21-23: LGTM! Class export and documentation updated.The changes correctly:
- Update JSDoc to reference "WorldState" generically
- Change from default export to named export for
WorldStateObjectThis is a critical change as
WorldStateObjectserves as the base class for many models across the codebase.
30-35: LGTM! Documentation updated for consistency.The JSDoc comments now consistently reference
WorldStateObject, aligning with the class naming.tsconfig.json (1)
14-22: LGTM! Path aliases configured for cleaner imports.The path aliases are well-structured and enable the cleaner import syntax used throughout the codebase. The configuration correctly maps:
@/modelsto the models barrel and individual model files@/supportingto the supporting barrel and files@/data/*to test data@/*as a general lib directory aliastest/unit/kinepage.spec.ts (1)
4-4: LGTM!The migration to the centralized barrel import with a named export aligns perfectly with the PR's objective to expose types and aliases for external usage.
test/unit/syndicatejob.spec.ts (2)
3-10: LGTM!The migration to alias-based imports with JSON import attributes is clean and consistent with the broader refactoring objectives.
20-30: LGTM!The multiline formatting of constructor invocations improves readability.
test/unit/darksector.spec.ts (1)
3-3: LGTM!The switch to named imports from the centralized barrel is consistent with the PR's refactoring objectives.
test/unit/globalupgrade.spec.ts (1)
3-3: LGTM!The migration to alias-based named imports is consistent with the broader refactoring pattern.
lib/models/Simaris.ts (1)
13-13: LGTM!The conversion from default export to named export aligns with the PR's objective to improve the public API surface.
lib/supporting/index.ts (1)
1-8: LGTM!The barrel export consolidates supporting modules into a single entry point, enabling cleaner imports across the codebase and better external API exposure.
test/unit/kuva.spec.ts (2)
3-5: LGTM!The migration to alias-based imports with JSON import attributes is clean and consistent with the centralized API pattern.
9-9: LGTM!Minor formatting improvement to the type annotation.
test/unit/archimedea.spec.ts (2)
4-5: LGTM!The migration to alias-based imports is consistent with the broader refactoring pattern.
13-23: LGTM!The test correctly uses the Archimedea class through the centralized barrel import.
lib/models/ZarimanCycle.ts (1)
3-3: LGTM! Export refactoring applied correctly.The changes properly update the base class import to use the renamed
WorldStateObjectand convert to a named export, consistent with the PR's objective to expose more types for external usage.Also applies to: 23-25
lib/models/ConclaveChallenge.ts (1)
12-12: LGTM! Base class and export updated correctly.The changes properly update to use
WorldStateObjectand convert to a named export, consistent with the PR's refactoring objectives.Also applies to: 25-27
lib/models/Invasion.ts (1)
10-13: LGTM! Import paths and export refactoring applied correctly.The changes properly update imports to use path aliases and convert to a named export, aligning with the PR's objective to expose more types for external usage.
Also applies to: 51-51
lib/models/ConstructionProgress.ts (1)
3-3: LGTM! Export refactoring applied correctly.The changes properly update to use the renamed
WorldStateObjectand convert to a named export, consistent with the PR's objectives.Also applies to: 7-9
lib/models/Archimedea.ts (1)
11-13: LGTM! Import paths and export refactoring applied correctly.The changes properly update imports to use path aliases and convert to a named export, consistent with the PR's refactoring objectives.
Also applies to: 103-103
test/integration/integration.spec.ts (1)
9-11: LGTM! Test imports updated to use path aliases.The changes properly update test imports to use the new path aliases, aligning with the PR's refactoring to improve import paths across the codebase.
lib/supporting/DuviriChoice.ts (1)
1-1: LGTM! Import path and export refactoring applied correctly.The changes properly update the import to use the models barrel export and convert to a named export, consistent with the PR's objectives.
Also applies to: 11-11
test/unit/sentientOutpost.spec.ts (1)
4-5: LGTM! Test imports updated to use path aliases.The changes properly update test imports to use the new path aliases, consistent with the PR's refactoring objectives.
lib/models/CetusCycle.ts (2)
2-3: LGTM!The refactoring to named exports and the updated
WorldStateObjectimport (capital S) aligns with the PR's goal of standardizing exports for external usage. The class correctly extends the base class with proper JSDoc updates.Also applies to: 23-23, 25-25
103-110: Formatting improvements look good.The multiline ternary and
Dateconstruction improve readability without changing behavior.test/unit/system.spec.ts (2)
2-7: LGTM!The migration to path aliases (
@/supporting,@/data/...) improves import clarity and aligns with the project-wide alias standardization. ThefetchProxy as fetchrename maintains backward-compatible usage.
15-18: Formatting adjustment is fine.The multiline object parameter improves readability without changing behavior.
lib/models/VoidTraderSchedule.ts (1)
1-5: Named export and multiline import formatting look good.The class export change aligns with the PR's standardization effort.
Also applies to: 9-9
lib/models/CambionCycle.ts (2)
3-4: LGTM!The migration to named exports and
WorldStateObject(capital S) is correctly implemented. Usingimport typeforCetusCycleis appropriate since it's only used as a type annotation.Also applies to: 8-8, 10-10
20-24: Destructuring assignment formatting is clean.The multiline formatting improves readability of the property extraction from
cetusCycle.lib/models/Kuva.ts (2)
6-7: Path alias imports look correct.The
@/supporting/ExternalMissionand@/supporting/KuvaLogEntryimports use the proper alias format.
37-38: LGTM!The reformatting changes improve readability, and the named export aligns with the PR's standardization effort.
Also applies to: 47-50, 63-63, 93-93
lib/models/Calendar.ts (2)
5-8: LGTM!Import restructuring correctly adds
translateSeasonand importsWorldStateObjectwithBaseContentObjecttype from the local module.
44-45: Formatting and export changes look good.The multiline formatting improves readability, and the named export pattern is consistent with the PR's goals. Based on learnings,
calendar.Daysis always present and an array, so the existing null-check in the constructor remains appropriately defensive.Also applies to: 57-60, 65-65, 85-85
lib/models/FlashSale.ts (2)
8-10: LGTM!The imports correctly use the
@/supportingalias forDependencyand a relative path for the localWorldStateObjectmodule. This is the expected pattern for cross-module vs same-directory imports.
27-27: Named export and constructor formatting look good.The refactoring to a named export is consistent with the PR's standardization effort. The multiline constructor signature improves readability.
Also applies to: 73-77
lib/models/WeeklyChallenge.ts (2)
1-5: LGTM!The multiline import formatting improves readability. The named export and
WorldStateObjectbase class are correctly implemented with updated JSDoc.Also applies to: 13-13, 15-15
23-25: Formatting improvement is clean.The multiline map callback formatting is more readable.
lib/models/SentientOutpost.ts (1)
40-93: LGTM!The conversion to named export and the addition of explicit public properties align well with the PR objectives. The data-driven override logic for
activationandexpiry(lines 87-92) correctly provides defaults fromsat()that can be superseded bysentientDatawhen available.lib/models/Mission.ts (1)
40-230: LGTM!The conversion to named export and the formatting adjustments preserve all behavior while improving consistency. The multiline formatting for array mappings (lines 206-227) enhances readability.
lib/models/Sortie.ts (1)
29-92: LGTM!The base class update to
WorldStateObjectand the conversion to named export are consistent with the project-wide refactor. The multiline formatting for the variants mapping (lines 81-83) improves readability.lib/models/VoidTrader.ts (2)
10-10: Correct import path pattern observed.This file uses
@/supporting(without the./prefix), which differs from the./@/supporting/Dependencypattern in SentientOutpost.ts, Mission.ts, and Sortie.ts. This suggests those files have incorrect import paths.The verification script from the earlier comment will help identify all instances of the inconsistent pattern.
29-92: LGTM!The conversion to named export and the base class update to
WorldStateObjectare consistent with the refactor. The character handling logic (lines 78-80) correctly maintains the fallback behavior, and the multiline array mappings improve readability.lib/models/Nightwave.ts (1)
27-87: LGTM!The base class update to
WorldStateObjectand the conversion to named export align with the project-wide refactor. The JSDoc description update (line 24) correctly addresses the previous review feedback.lib/models/DarkSector.ts (1)
48-225: LGTM!The base class update to
WorldStateObject, the conversion to named export, and the multiline formatting adjustments all preserve existing behavior while improving consistency with the project-wide refactor.lib/models/Fissure.ts (1)
31-138: LGTM!The base class update to
WorldStateObjectand the new public property initializations (lines 116-122) are correct. The conversion to named export and multiline formatting improve consistency.lib/models/SyndicateJob.ts (1)
115-261: LGTM!The base class update to
WorldStateObjectand conversion to named export are consistent with the refactor. The chamber extraction logic (lines 228-232) correctly addresses the ReDoS vulnerability from the previous review by replacing the problematic backtracking regex with two safe replacements.lib/models/News.ts (1)
10-13: LGTM! Refactoring improves public API and maintainability.The changes successfully:
- Convert to named export for better tree-shaking and explicit imports
- Fix the naming inconsistency (WorldstateObject → WorldStateObject)
- Adopt path aliases (@/supporting) for cleaner import paths
- Improve code readability with multiline formatting
These are consistent with the PR's objective to export more types and improve the public API surface.
Also applies to: 34-36, 91-99, 101-105, 112-116, 119-121, 132-136, 187-189
lib/models/SyndicateMission.ts (1)
1-11: LGTM! Refactoring aligns with broader API improvements.The changes successfully:
- Convert to named export (export class SyndicateMission)
- Fix the WorldstateObject → WorldStateObject naming
- Adopt path aliases for imports (@/supporting)
- Improve readability with multiline method signatures
These changes are consistent with the PR's goal of making types and classes available for external usage.
Also applies to: 21-23, 54-57, 60-64, 77-80
lib/models/WorldEvent.ts (1)
11-19: LGTM! Refactoring successfully improves the public API.The changes effectively:
- Convert to named export (export class WorldEvent)
- Fix WorldstateObject → WorldStateObject naming throughout
- Adopt path aliases (@/supporting) for cleaner imports
- Improve code readability with multiline formatting for long expressions
These changes align with the PR's objective of exporting types for external usage.
Also applies to: 90-92, 233-236, 261-264, 281-283, 287-289, 291-293, 295-297, 306-308, 354-356, 358-360
lib/models/index.ts (1)
1-42: LGTM! Central barrel export improves developer experience.This new index file creates a unified public API entry point for all model classes and types. The barrel export pattern:
- Enables clean imports:
import { News, Alert, WorldEvent } from '@/models'- Centralizes the public API surface
- Supports the path alias strategy used throughout the codebase
- Makes it easier for external consumers to import multiple models
This directly fulfills the PR's objective of "export more types and import aliases to allow external usage."
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
lib/models/WorldEvent.ts (1)
343-350: Bug fix applied successfully; consider simplifying the outer wrapper.The string concatenation bug flagged in the previous review has been correctly fixed by adding an initial value of
0and converting each element to a number. However, the outerString()andNumber.parseFloat()wrapper is redundant since thereducealready returns a number.🔎 Suggested simplification
- this.progressTotal = Number.parseFloat( - String( - data.MultiProgress!.reduce( - (acc, val) => acc + Number.parseFloat(val), - 0 - ) - ) - ); + this.progressTotal = data.MultiProgress!.reduce( + (acc, val) => acc + Number.parseFloat(val), + 0 + );
🧹 Nitpick comments (4)
lib/models/Fissure.ts (2)
117-119: Potential code duplication with base class.The base class
WorldStateObjectalready handlesactivationandexpiryin its constructor (called viasuper(data)on line 92). These lines reassign the same fields, duplicating the parsing logic.Since
RawFissuredefinesActivationandExpiryas required fields, these assignments will always execute. Consider whether these lines can be removed to rely on the base class implementation, or if there's a specific reason Fissure needs to override this behavior.🔎 Verification script to check if other models also reassign these fields
#!/bin/bash # Check if other model classes that extend WorldStateObject also reassign activation/expiry ast-grep --pattern $'class $_ extends WorldStateObject { $$$ constructor($$$) { $$$ this.activation = $$$ $$$ } $$$ }'
129-138: Consider defensive null handling in getters.Both getters use non-null assertions (
this.expiry!), which assumeexpiryis always defined. While this is likely safe given thatRawFissurerequiresExpiry, consider adding defensive checks for robustness:get expired(): boolean { return this.expiry ? fromNow(this.expiry) < 0 : false; } get eta(): string { return this.expiry ? timeDeltaToString(fromNow(this.expiry)) : ''; }This would prevent runtime errors if
expiryis unexpectedly undefined.lib/models/GlobalUpgrade.ts (1)
10-11: Consider using the barrel export for consistency.The import path has been corrected from the malformed
./@/supporting/Dependencyto@/supporting/Dependencyand resolves correctly. However, the barrel export at@/supportingincludesDependency, so the import can be simplified toimport type { Dependency } from '@/supporting';for consistency with the project's export patterns.lib/supporting/DuviriChoice.ts (1)
17-23: Consider adding a default case for defensive coding.While the
RawChoiceinterface constrainsCategoryto only two values, adding a default case would provide runtime safety if the API returns unexpected data.🔎 Proposed defensive default case
switch (data.Category) { case 'EXC_NORMAL': this.category = 'normal'; break; case 'EXC_HARD': this.category = 'hard'; + break; + default: + this.category = 'unknown'; }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (18)
lib/models/ChallengeInstance.tslib/models/ConclaveChallenge.tslib/models/DailyDeal.tslib/models/DuviriCycle.tslib/models/Fissure.tslib/models/GlobalUpgrade.tslib/models/Kuva.tslib/models/Mission.tslib/models/Reward.tslib/models/SentientOutpost.tslib/models/Simaris.tslib/models/Sortie.tslib/models/Tmp.tslib/models/VoidTraderSchedule.tslib/models/WorldEvent.tslib/supporting/DuviriChoice.tspackage.jsontest/testclient.ts
🚧 Files skipped from review as they are similar to previous changes (6)
- package.json
- lib/models/Kuva.ts
- lib/models/Tmp.ts
- lib/models/DuviriCycle.ts
- lib/models/Reward.ts
- test/testclient.ts
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-16T02:24:30.860Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 702
File: lib/models/Archidemea.ts:74-90
Timestamp: 2025-10-16T02:24:30.860Z
Learning: In Warframe's Archimedea/Conquest data structure (lib/models/Archidemea.ts), Digital Extremes duplicates difficulties when adding hard tier risks. The first risk in higher difficulties (e.g., CD_HARD) is always identical to the one in the normal difficulty (CD_NORMAL), so using `slice(1)` to skip the first risk when processing additional difficulties is the correct approach to avoid duplicates.
Applied to files:
lib/models/ChallengeInstance.tslib/models/Mission.ts
🧬 Code graph analysis (8)
lib/models/ChallengeInstance.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/SentientOutpost.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/Fissure.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/DailyDeal.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/WorldEvent.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/Sortie.ts (3)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/SortieVariant.ts (1)
SortieVariant(21-76)
lib/models/Mission.ts (3)
lib/models/SentientOutpost.ts (1)
Mission(30-34)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/Reward.ts (1)
Reward(31-108)
lib/models/ConclaveChallenge.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Test (20)
- GitHub Check: Coverage
🔇 Additional comments (29)
lib/models/Simaris.ts (2)
2-3: LGTM!The import path has been correctly updated to use the alias-based path
@/supporting/Dependency, aligning with the PR's goal of enabling external usage through path aliases. The previously flagged malformed path issue has been resolved.
13-18: LGTM!The change from default export to named export aligns with the PR's broader refactoring goal. Consumers will need to update from
import Simaris from '...'toimport { Simaris } from '...', but this is intentional and the barrel export inlib/models/index.tswill properly re-export the class.lib/models/ConclaveChallenge.ts (3)
10-13: Import paths look correct.The path alias
@/supporting/Dependencyis properly formatted (the previously reported./@/issue has been addressed). The combination of alias imports for supporting modules and relative imports for sibling model files is reasonable.
26-28: Named export and base class alignment look good.The switch from default to named export enables cleaner imports for external consumers. The
WorldStateObjectcapitalization now matches the actual class definition.
79-82: Formatting improvements.The multiline formatting for the constructor signature and object destructuring enhances readability without changing behavior.
Also applies to: 103-107
lib/models/WorldEvent.ts (2)
11-19: Import restructuring looks good.The updated imports correctly use the new path aliases (
@/supporting) and named exports, aligning with the PR objectives to enable external usage of common/shared types.
90-92: Export style and base class updates are correct.The change from default to named export and the base class rename from
WorldstateObjecttoWorldStateObjectalign with the PR objectives. The JSDoc@augmentsannotation is correctly updated to match.lib/models/ChallengeInstance.ts (2)
3-3: Import path issue resolved.The import correctly uses the
@/alias without the./prefix, addressing the previous review feedback.
18-18: Named export migration verified correctly.The change to named export in
ChallengeInstance.tsis properly implemented. The consumer file (WeeklyChallenge.ts) correctly imports using named syntax:import { ChallengeInstance, type RawChallengeInstance } from './ChallengeInstance'. The barrel export inlib/models/index.tsalso properly re-exports the named export. No violations found.lib/models/VoidTraderSchedule.ts (2)
1-5: LGTM!The import restructuring is clean and properly uses the
typemodifier for the type-only import ofContentTimestamp.
9-9: LGTM!The migration from default export to named export aligns with the PR objectives to "export more types" and enables better external usage of this model.
lib/models/DailyDeal.ts (3)
72-75: LGTM!The constructor signature reformatting improves readability without changing semantics. The defensive default parameter pattern correctly handles both undefined
depsparameter and undefinedlocaleproperty.
26-26: LGTM! All imports correctly use the named import pattern.The class declaration correctly extends
WorldStateObjectand uses a named export. The single import found in the test file (test/unit/dailydeal.spec.ts) properly imports using the named pattern from the barrel export, and no incorrect default imports exist.
8-10: Approved. The import changes correctly adopt the@/supporting/path alias for the Dependency type and properly reference the renamedWorldStateObjectbase class. The@/path alias is properly configured intsconfig.json, andDailyDealis correctly exported as a named export through thelib/models/index.tsbarrel file.lib/models/Fissure.ts (3)
13-16: LGTM! Import aliases and named imports look good.The updated imports correctly use path aliases (
@/supporting/Dependency) and named imports (WorldStateObject), which aligns with the PR's objective to enable better external usage and maintainability.
32-32: LGTM! Named export aligns with PR objectives.The change from default export to named export (
export class Fissure) enables explicit imports and better tree-shaking for external consumers.
88-91: LGTM! Formatting improvements enhance readability.The constructor parameter formatting and multi-line assignments improve code readability without affecting functionality.
Also applies to: 96-102, 110-113
lib/models/SentientOutpost.ts (3)
1-7: LGTM!The import changes are correct. Named imports from
warframe-worldstate-data/utilitiesand the type-only import using the@/supporting/Dependencyalias are properly structured.
11-25: Comment-code discrepancy insat()function.The comment on line 13 says "One cycle = 3 hours" but
durationis 1800 seconds (30 minutes). Additionally, the comment on line 15 mentions "active range is after 30m and lasts for 30m" but the conditioncycleSeconds > 0 && cycleSeconds < 1800makesactivetrue for nearly the entire cycle (1-1799 seconds), only false at the exact start (0).Please verify if this logic is intentional or if the comments/logic need updating.
30-34: LGTM!The
Missioninterface andSentientOutpostclass are correctly exported as named exports. The class properly initializes all public fields and handles the optionalsentientDataoverride for activation/expiry dates.Also applies to: 40-93
lib/models/Sortie.ts (2)
10-15: LGTM!Import statements are well-organized with type-only imports properly using the
typekeyword and the@/supporting/Dependencypath alias. Named imports forMission,SortieVariant, andWorldStateObjectalign with the broader named export refactoring.
26-30: LGTM!The JSDoc
@augmentsannotation correctly references the renamedWorldStateObject. Constructor and variants mapping reformatting improves readability without changing behavior.Also applies to: 66-69, 82-84
lib/models/Mission.ts (2)
1-11: LGTM!Import statements are correctly structured with named imports from
warframe-worldstate-data/utilities, type-only import forDependencyusing the path alias, and properly organized local imports.
166-169: LGTM!Constructor and field assignment reformatting improves readability. The multiline formatting for conditional assignments and array mappings follows consistent patterns without changing behavior.
Also applies to: 187-189, 207-227
lib/models/GlobalUpgrade.ts (4)
1-8: LGTM! Missing import added.The
upgradefunction was being used at line 57 but wasn't previously imported. This change correctly adds it to the import statement.
51-54: LGTM! Formatting improvement.The constructor parameters have been formatted to span multiple lines for better readability. No functional changes.
12-12: Base class rename is complete and consistent.The import of
WorldStateObjectandBaseContentObjectfrom./WorldStateObjectis correct. The file exists, properly exports both the class and interface, and there are no remaining references to the oldWorldstateObjectnaming throughout the codebase.
25-25: Export change verified - all consumers properly updated.The conversion from default to named export has been successfully implemented across the codebase. Verification confirms no remaining default imports exist, and all files now use the correct named import pattern:
import { GlobalUpgrade, type RawGlobalUpgrade } from '@/models'Tests and the main
WorldState.tsconsumer have been properly updated.lib/supporting/DuviriChoice.ts (1)
11-11: All imports correctly use named import syntax.Verification confirms that DuviriChoice has been successfully converted to a named export (line 11:
export class DuviriChoice), is properly re-exported through the barrel file, and all import sites are correctly updated:
lib/WorldState.ts:import { DuviriChoice, type RawChoice } from '@/supporting'lib/models/DuviriCycle.ts:import type { DuviriChoice } from '@/supporting/DuviriChoice'No remaining default imports found.
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (4)
test/unit/simaris.spec.ts (1)
18-20: Double type cast bypasses type safety.The test uses
{} as unknown as undefinedto bypass TypeScript's type checking. While this may intentionally test edge-case behavior, the double cast is a code smell.Consider either:
- Removing this test if passing an empty object is not a valid use case
- Using a single cast if the intent is to test runtime behavior with unexpected types
test/unit/fissure.spec.ts (1)
10-15: LGTM! Consider adding positive test cases.The test assertions correctly verify that the constructor throws TypeError with invalid inputs using proper chai syntax.
While the error case coverage is good, consider adding tests for valid constructor behavior to ensure the Fissure class properly initializes its properties (node, missionType, enemy, tier, etc.) with valid RawFissure data. This would provide more comprehensive coverage.
Example test structure for valid input
it('should create a Fissure instance with valid data', () => { const mockData: RawFissure = { Node: 'SolNode1', MissionType: 'MT_EXCAVATE', Modifier: 'VoidT1', ActiveMissionTier: '', Activation: { sec: 1234567890 }, Expiry: { sec: 1234567900 } }; const fissure = new Fissure(mockData); expect(fissure.node).to.be.a('string'); expect(fissure.missionType).to.be.a('string'); expect(fissure.tier).to.be.a('string'); });test/unit/darksector.spec.ts (1)
5-14: LGTM! Expect-style assertions properly formed.The assertions are correctly converted to expect-style. The
.to.throw()calls without specific error types are valid, though slightly less specific than other test files that check forTypeError.💡 Optional: Add specific error type for clarity
For consistency with other test files (e.g., flashsale.spec.ts, mission.spec.ts), consider specifying
TypeError:expect(() => { new DarkSector(undefined as unknown as RawDarkSector); - }).to.throw(); + }).to.throw(TypeError); expect(() => { new DarkSector({} as RawDarkSector); - }).to.throw(); + }).to.throw(TypeError);lib/models/SentientOutpost.ts (1)
9-25: Consider removing unusedactivefield fromsat()return value.The
sat()function calculates and returns anactiveboolean (line 16, 21), but the constructor only destructuresactivationandexpiry(line 83), leaving theactivefield unused. The class instead sets its ownactivebased on mission presence (line 84).This creates confusion between two different concepts of "active": time-based vs. mission-based.
🔎 Proposed refactor
const sat = () => { const now = Math.floor(Date.now() / 1000); // One cycle = 3 hours const cycleSeconds = now % duration; - // active range is after 30m and lasts for 30m - const active = cycleSeconds > 0 && cycleSeconds < 1800; const start = (now - cycleSeconds) * 1000; const end = (now - cycleSeconds + duration) * 1000; return { - active, expiry: new Date(end), activation: new Date(start), }; };
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (39)
lib/models/SentientOutpost.tslib/supporting/DuviriChoice.tslib/supporting/KuvaLogEntry.tspackage.jsontest/data/LanguageNews.jsontest/data/News.jsontest/integration/integration.spec.tstest/unit/alert.spec.tstest/unit/archimedea.spec.tstest/unit/calendar.spec.tstest/unit/cambion.spec.tstest/unit/cetus.spec.tstest/unit/conclavechallenge.spec.tstest/unit/construction.spec.tstest/unit/dailydeal.spec.tstest/unit/darksector.spec.tstest/unit/earth_cycle.spec.tstest/unit/event.spec.tstest/unit/fissure.spec.tstest/unit/flashsale.spec.tstest/unit/globalupgrade.spec.tstest/unit/invasion.spec.tstest/unit/kinepage.spec.tstest/unit/kuva.spec.tstest/unit/mission.spec.tstest/unit/news.spec.tstest/unit/nightwave.spec.tstest/unit/persistentenemy.spec.tstest/unit/reward.spec.tstest/unit/sentientOutpost.spec.tstest/unit/simaris.spec.tstest/unit/sortie.spec.tstest/unit/sortievariant.spec.tstest/unit/syndicatejob.spec.tstest/unit/syndicatemission.spec.tstest/unit/system.spec.tstest/unit/voidtrader.spec.tstest/unit/worldstate.spec.tstest/unit/zariman.spec.ts
🚧 Files skipped from review as they are similar to previous changes (17)
- test/unit/calendar.spec.ts
- test/unit/nightwave.spec.ts
- test/unit/earth_cycle.spec.ts
- test/unit/cambion.spec.ts
- test/integration/integration.spec.ts
- test/unit/kuva.spec.ts
- test/unit/kinepage.spec.ts
- test/unit/alert.spec.ts
- test/unit/worldstate.spec.ts
- test/unit/invasion.spec.ts
- test/unit/sortievariant.spec.ts
- test/unit/dailydeal.spec.ts
- lib/supporting/KuvaLogEntry.ts
- test/unit/system.spec.ts
- test/unit/globalupgrade.spec.ts
- test/unit/zariman.spec.ts
- test/unit/sentientOutpost.spec.ts
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-16T02:24:30.860Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 702
File: lib/models/Archidemea.ts:74-90
Timestamp: 2025-10-16T02:24:30.860Z
Learning: In Warframe's Archimedea/Conquest data structure (lib/models/Archidemea.ts), Digital Extremes duplicates difficulties when adding hard tier risks. The first risk in higher difficulties (e.g., CD_HARD) is always identical to the one in the normal difficulty (CD_NORMAL), so using `slice(1)` to skip the first risk when processing additional difficulties is the correct approach to avoid duplicates.
Applied to files:
test/unit/voidtrader.spec.tslib/supporting/DuviriChoice.ts
🧬 Code graph analysis (15)
test/unit/simaris.spec.ts (1)
lib/models/Simaris.ts (1)
Simaris(13-48)
test/unit/flashsale.spec.ts (1)
lib/models/FlashSale.ts (2)
FlashSale(27-109)RawFlashSale(12-22)
test/unit/sortie.spec.ts (1)
lib/models/Sortie.ts (2)
Sortie(30-108)RawSortie(19-24)
test/unit/syndicatejob.spec.ts (1)
lib/models/SyndicateJob.ts (2)
SyndicateJob(115-262)RawSyndicateJob(95-105)
test/unit/persistentenemy.spec.ts (1)
lib/models/PersistentEnemy.ts (2)
PersistentEnemy(29-118)RawPersistentEnemy(12-23)
test/unit/event.spec.ts (1)
lib/models/WorldEvent.ts (2)
WorldEvent(92-394)RawWorldEvent(47-86)
test/unit/cetus.spec.ts (1)
lib/models/CetusCycle.ts (1)
CetusCycle(25-122)
test/unit/construction.spec.ts (1)
lib/models/ConstructionProgress.ts (1)
ConstructionProgress(9-30)
test/unit/reward.spec.ts (1)
lib/models/Reward.ts (3)
Reward(31-108)RawReward(22-26)getItemType(9-12)
test/unit/archimedea.spec.ts (1)
lib/models/Archimedea.ts (2)
Archimedea(103-154)RawArchimedea(20-24)
lib/models/SentientOutpost.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
test/unit/news.spec.ts (1)
lib/models/News.ts (2)
News(36-191)RawNews(20-30)
test/unit/syndicatemission.spec.ts (1)
lib/models/SyndicateMission.ts (2)
SyndicateMission(23-96)RawSyndicateMission(13-17)
test/unit/fissure.spec.ts (1)
lib/models/Fissure.ts (2)
Fissure(32-139)RawFissure(18-26)
test/unit/mission.spec.ts (1)
lib/models/Mission.ts (2)
Mission(41-231)RawMission(13-36)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Test (20)
- GitHub Check: Coverage
🔇 Additional comments (54)
lib/supporting/DuviriChoice.ts (3)
1-1: LGTM: Import alias correctly configured.The switch to the
@/modelspath alias is valid and aligns with the broader refactor to use TypeScript path mappings for improved maintainability.
11-11: Named export enables external usage.The switch from default to named export is intentional and aligns with the PR objective to enable external usage of common/shared types. This is a breaking change for existing consumers but improves API flexibility.
23-25: Previous review concern addressed.The addition of the
breakstatement anddefaultcase properly addresses the feedback from the previous review, preventing potential fallthrough and adding defensive error handling for unknown categories.test/unit/simaris.spec.ts (1)
3-3: LGTM: Import path updated to use named export and path alias.The change from a default import to a named import from '@/models' aligns with the PR's objective to expose types for external usage. The path alias is correctly configured in
tsconfig.jsonand Simaris is properly re-exported from thelib/modelsbarrel file.test/unit/sortie.spec.ts (2)
5-5: LGTM! Assertion style migration is correct.The migration from
shouldtoexpectassertion style is implemented correctly and improves code clarity. The test logic remains unchanged and properly verifies that constructing aSortiewith invalid arguments throws aTypeError.Also applies to: 10-15
3-3: Import changes look good.The
@/modelspath alias is properly configured intsconfig.json(mapping to./lib/models/index), and the barrel export atlib/models/index.tscorrectly re-exports bothSortieandRawSortie. The use of thetypemodifier forRawSortiefollows TypeScript best practices for type-only imports.test/unit/cetus.spec.ts (2)
5-5: LGTM! Consistent assertion style refactoring.The migration from chai's
shouldtoexpectstyle is applied consistently throughout the test file. All assertion syntax is correct:
- TypeError throwing tests use proper
expect(() => {}).to.throw(TypeError)pattern- Boolean equality checks use
expect(value).to.equal(true/false)- String inclusion checks use
expect(value).to.include(string)The test logic and coverage are preserved correctly.
Also applies to: 10-15, 21-21, 27-27, 32-32
3-3: LGTM! Path alias is correctly configured.The import path change from relative to aliased import (
@/models) correctly aligns with the PR objective of enabling external usage of common types. The path alias is properly configured in tsconfig.json to resolve@/modelsto./lib/models/index, which re-exports CetusCycle. The named import syntax is appropriate for the refactored exports.test/unit/archimedea.spec.ts (4)
9-9: LGTM!Extracting
expectfrom chai is the standard approach for expect-style assertions and improves code clarity.
14-14: LGTM!The type casting to
RawArchimedeais necessary and correct for JSON imports, and the constructor usage aligns with the class definition.
16-16: LGTM!The migration to expect-style assertion is correctly implemented.
4-5: Path aliases and import attributes configuration is correctly set up.The import statements follow the configured path aliases:
@/modelscorrectly resolves to./lib/models/index@/data/Conquest.jsoncorrectly resolves totest/data/Conquest.jsonTypeScript 5.9.3 fully supports the import attributes syntax (
with { type: 'json' }), exceeding the minimum requirement of 5.3.test/unit/persistentenemy.spec.ts (3)
5-5: LGTM!Standard chai expect pattern that supports the new assertion style.
10-15: LGTM!The migration from
should()toexpect()style assertions preserves the test logic while using more explicit syntax.
3-3: Import changes are properly configured.The
@/modelspath alias is correctly mapped tolib/models/index.tsintsconfig.json, and the barrel export properly re-exports bothPersistentEnemyandRawPersistentEnemy. The migration from relative default import to named imports from the alias is valid and aligns with the PR objectives.package.json (2)
41-42: LGTM! Updated to use recommended Biome commands.The change from
biome linttobiome checkis a best practice, ascheckruns both linting and formatting, providing more comprehensive code quality checks.
46-46: LGTM! Necessary for path alias support.Adding the
pretestbuild step is appropriate given the introduction of TypeScript path aliases mentioned in the PR. This ensures tests run against properly built code with resolved module paths.test/unit/voidtrader.spec.ts (2)
3-4: LGTM! Import changes align with PR objectives.The migration to barrel exports (
@/modelsand@/supporting) successfully implements the PR's goal to "export more types and add import aliases to enable external usage of common/shared types."
16-27: LGTM! Test logic preserved correctly.The formatting changes maintain the original test coverage: proper validation of constructor type checks and successful instantiation with valid data.
test/unit/fissure.spec.ts (2)
5-5: LGTM! Standard chai expect pattern.The declaration follows standard chai testing practices and supports the migration to expect-style assertions.
3-3: Import changes look good. The@/modelspath alias is properly configured in tsconfig.json, the migration to named exports is correct, and thetypekeyword for RawFissure follows TypeScript best practices. This aligns well with the PR's objective to enable external usage of common types.test/unit/conclavechallenge.spec.ts (2)
8-8: LGTM! Assertion style migration completed correctly.The migration from
should-based assertions toexpect-based assertions is implemented correctly throughout the test:
- Error assertions properly use
expect(() => { ... }).to.throw(TypeError)- Non-error assertions use
expect(() => { ... }).to.not.throw()- Existence checks correctly use
expect(...).to.existThe assertion patterns are consistent and follow Chai best practices.
Also applies to: 13-18, 25-25, 28-30
3-6: Path aliases and JSON import assertions are properly configured and compatible.The imports are correctly configured:
- Path aliases are defined in
tsconfig.jsonand resolve to the appropriate directories (@/models→./lib/models/index,@/data/*→test/data/*, etc.).- TypeScript version
5.9.3supports JSON import assertions (requirement: 5.3+).- Node.js version
24.3.0provides stable support for JSON import assertions (requirement: 20.10+).The pattern is already established throughout the codebase with no configuration issues.
test/data/LanguageNews.json (1)
3-9: LGTM! Consistent test data format updates.The changes correctly update date fields to MongoDB extended JSON format ($date with $numberLong) and normalize empty field representations. This aligns with the data format standardization across the test suite.
test/unit/flashsale.spec.ts (2)
3-3: LGTM! Clean migration to named exports and path aliases.The import update correctly uses named exports from the centralized '@/models' alias, improving maintainability and aligning with the public API surface changes across the PR.
5-15: LGTM! Proper expect-style assertion migration.The test assertions are correctly migrated from should-style to expect-style with proper error type checking (TypeError). The test semantics remain unchanged.
test/unit/event.spec.ts (2)
3-4: LGTM! Consistent import modernization.The imports correctly use named exports from '@/models' and the proper TypeScript JSON import syntax with the type assertion. This aligns with the broader refactoring to centralize public API exports.
6-23: LGTM! Correct expect-style assertions.All assertions are properly formed with parentheses (e.g.,
.to.not.throw()), correctly addressing the previous review comment. The test logic remains functionally equivalent.test/unit/construction.spec.ts (2)
3-3: LGTM! Named export with specific path.The import uses a specific path '@/models/ConstructionProgress' rather than the barrel export '@/models'. This is valid and may be intentional for direct imports.
5-31: LGTM! Comprehensive expect-style migration.All assertions are correctly converted to expect-style, including error handling tests and property validation with regex patterns. The test coverage remains intact.
test/data/News.json (1)
3-9: LGTM! Consistent test data format updates.The date fields are correctly updated to MongoDB extended JSON format, matching the standardization pattern applied across test data files (e.g., LanguageNews.json).
test/unit/syndicatemission.spec.ts (2)
3-3: LGTM! Consistent import migration.The import correctly uses named exports from the '@/models' alias, aligning with the project-wide refactoring to expose public types through centralized barrel exports.
5-15: LGTM! Proper assertion style conversion.The test assertions are correctly migrated to expect-style with appropriate TypeError validation. The test semantics are preserved.
test/unit/mission.spec.ts (2)
3-4: LGTM! Consistent import updates.The imports correctly use named exports from '@/models' and proper JSON import syntax, aligning with the broader API surface refactoring.
6-24: LGTM! Proper expect-style assertions.All test assertions are correctly converted to expect-style with appropriate error handling validation.
test/unit/darksector.spec.ts (1)
3-3: LGTM! Consistent import migration.The import correctly uses named exports from the '@/models' alias, matching the pattern applied across all test files in this PR.
test/unit/reward.spec.ts (4)
5-5: LGTM! Import path updated to use centralized exports.The import correctly uses the new path alias
@/modelsand named exports, aligning with the PR's objective to centralize public API exports.
7-7: LGTM! Test style migration to expect.The addition of
const expect = chai.expect;supports the migration from should-style to expect-style assertions throughout the test suite.
13-18: LGTM! Assertion style updated consistently.The migration from should-style to expect-style assertions (
expect(...).to.throw(TypeError)) preserves the test behavior while standardizing on expect syntax.
39-42: LGTM! Test assertions migrated to expect style.The assertions correctly use expect syntax while maintaining the original test logic for item type categorization and spy verification.
test/unit/syndicatejob.spec.ts (5)
3-3: LGTM! Import path updated to use centralized exports.The import correctly uses the path alias
@/modelswith named exports, consistent with the PR's public API centralization.
12-12: LGTM! Test style migration to expect.The setup correctly adds
const expect = chai.expect;to support expect-style assertions.
19-31: LGTM! Constructor test assertions updated to expect style.The multi-line formatting improves readability, and the expect-style assertions correctly preserve the original test behavior for invalid constructor arguments.
40-41: LGTM! Reward pool assertions migrated to expect style.The assertions correctly use expect syntax (
expect(...).to.be.an('array'),expect(...).to.be.at.least(1)) while maintaining the original validation logic.
4-10: JSON import attributes syntax is fully supported in this project.The project uses TypeScript 5.9.3 and Node.js 24.3.0, both well above the minimum requirements for the
with { type: 'json' }syntax. The tsconfig.json is properly configured withmodule: "esnext",target: "es2024", andmoduleResolution: "bundler"for modern module resolution.test/unit/news.spec.ts (6)
3-6: LGTM! Imports updated to use centralized exports and path aliases.The imports correctly use
@/modelsfor named exports and@/datafor test fixtures with the modern JSON import attributes syntax, aligning with the PR's centralization objectives.
8-8: LGTM! Test style migration to expect.The setup correctly adds
const expect = chai.expect;to support the expect-style assertion migration.
15-20: LGTM! Constructor test assertions updated to expect style.The expect-style assertions correctly preserve the original test behavior for invalid constructor arguments.
30-51: LGTM! ETA and update test assertions migrated to expect style.The assertions correctly use expect syntax while maintaining the original test logic for ETA formatting, update detection, and stream detection.
58-105: LGTM! Link resolution test assertions updated to expect style.The test correctly validates link resolution from the Links array when Prop is empty, and properly tests the default fallback behavior using expect-style assertions.
112-137: LGTM! Prime access and title test assertions migrated to expect style.The assertions correctly use expect syntax while maintaining the original test logic for prime access detection and localized title retrieval.
lib/models/SentientOutpost.ts (3)
1-7: LGTM! Imports are correctly configured.The type-only import for
Dependencyuses the path alias correctly, and the consolidated named imports fromwarframe-worldstate-data/utilitiesfollow best practices.
30-34: LGTM! Interface is well-defined.The renamed
OutpostMissioninterface is clear and appropriately scoped with descriptive property names.
68-94: Clarifyactivefield semantics and the unusedsat().activevalue.The JSDoc states
activecaptures "whether or not the object was active during creation" (snapshot semantics). However,sat()computes a temporalactivevalue (30m active window in 3-hour cycle) that is never used. Additionally, whensentientDataoverridesactivation/expiry(lines 87-92),activeis not recalculated, making the embedded value inidstale. Confirm whether:
- The snapshot behavior is intentional (supporting the current code), or
- Temporal activity should drive
active(requiring recalculation aftersentientDataoverride and usingsat().active).
TobiTenno
force-pushed
the
aliases-exports-oh-my
branch
from
fed0c07 to
d199d7c
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
lib/models/Reward.ts (1)
82-88: Consider cachinggetTypesFull()result to avoid redundant computation.
getTypesFull()is called 4 times here, each performing array concatenation and mapping. Caching the result would improve performance, especially with larger reward lists.🔎 Proposed fix
- this.thumbnail = this.getTypesFull()[0] - ? this.getTypesFull()[0].thumbnail - : 'https://i.imgur.com/JCKyUXJ.png'; - - this.color = this.getTypesFull()[0] - ? this.getTypesFull()[0].color - : 0xf1c40f; + const firstType = this.getTypesFull()[0]; + this.thumbnail = firstType?.thumbnail ?? 'https://i.imgur.com/JCKyUXJ.png'; + this.color = firstType?.color ?? 0xf1c40f;lib/models/Fissure.ts (1)
117-119: Consider removing redundant activation/expiry assignments.The parent class
WorldStateObjectalready initializesactivationandexpiryin its constructor via thesuper(data)call on line 92. These assignments duplicate that behavior.Since
RawFissuredefinesActivationandExpiryas required fields, the parent's conditional logic will always execute for Fissure instances, making these assignments redundant.🔎 Proposed refactor to remove duplicate assignments
this.tierNum = fissureTier(data.Modifier || data.ActiveMissionTier, locale); - this.activation = parseDate(data.Activation); - - this.expiry = parseDate(data.Expiry); - this.isStorm = Boolean(data.ActiveMissionTier); this.isHard = Boolean(data.Hard);
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (16)
lib/models/ChallengeInstance.tslib/models/ConclaveChallenge.tslib/models/DailyDeal.tslib/models/Fissure.tslib/models/GlobalUpgrade.tslib/models/Mission.tslib/models/Reward.tslib/models/SentientOutpost.tslib/models/Simaris.tslib/models/Sortie.tslib/models/SortieVariant.tslib/models/Tmp.tslib/models/VoidTraderSchedule.tspackage.jsontest/unit/archimedea.spec.tstest/unit/mission.spec.ts
🚧 Files skipped from review as they are similar to previous changes (5)
- lib/models/ChallengeInstance.ts
- test/unit/mission.spec.ts
- package.json
- test/unit/archimedea.spec.ts
- lib/models/Tmp.ts
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-16T02:24:30.860Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-worldstate-parser PR: 702
File: lib/models/Archidemea.ts:74-90
Timestamp: 2025-10-16T02:24:30.860Z
Learning: In Warframe's Archimedea/Conquest data structure (lib/models/Archidemea.ts), Digital Extremes duplicates difficulties when adding hard tier risks. The first risk in higher difficulties (e.g., CD_HARD) is always identical to the one in the normal difficulty (CD_NORMAL), so using `slice(1)` to skip the first risk when processing additional difficulties is the correct approach to avoid duplicates.
Applied to files:
lib/models/Mission.tslib/models/SortieVariant.ts
🧬 Code graph analysis (9)
lib/models/ConclaveChallenge.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/DailyDeal.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/Mission.ts (2)
lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/Reward.ts (1)
Reward(31-108)
lib/models/SortieVariant.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/Reward.ts (2)
lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/supporting/RewardTypes.ts (1)
RewardType(8-33)
lib/models/SentientOutpost.ts (1)
lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/GlobalUpgrade.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
lib/models/Sortie.ts (3)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)lib/models/SortieVariant.ts (1)
SortieVariant(21-76)
lib/models/Fissure.ts (2)
lib/models/WorldStateObject.ts (1)
WorldStateObject(23-79)lib/supporting/Dependency.ts (1)
Dependency(9-39)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Test (20)
- GitHub Check: Coverage
🔇 Additional comments (39)
lib/models/VoidTraderSchedule.ts (1)
1-20: LGTM! Clean refactoring aligns with PR objectives.The changes successfully convert to named exports and improve import organization:
- Type-only import for
ContentTimestampfollows best practices- Dependency imported from the
@/supportingbarrel export (previous concerns addressed)- Named export enables external usage as intended by the PR
The implementation is correct and consistent with the architectural changes across the codebase.
lib/models/DailyDeal.ts (4)
10-10: LGTM!The named import of
WorldStateObjectis correct and aligns with the refactoring to named exports.
72-75: LGTM!The constructor formatting has been improved for readability with no semantic changes to the parameters or default values.
26-26: [rewritten comment]
[classification tag]
8-8: The path alias configuration is properly set up intsconfig.json. The@/supportingalias is correctly mapped to./lib/supporting/index, so this import will resolve correctly.lib/models/Simaris.ts (3)
1-48: LGTM! Changes align with PR objectives.The conversion from default export to named export and the use of path aliases for imports successfully achieves the PR's goal of enabling external usage of common/shared types. The functionality of the Simaris class remains intact.
3-3: Path alias and barrel export are correctly configured.The
@/supportingalias is properly defined intsconfig.json, andlib/supporting/index.tscorrectly exports theDependencytype via barrel export fromlib/supporting/Dependency.ts.
13-13: No action required: breaking change is properly handled.The export change from default to named export has been correctly implemented throughout the codebase. All internal consumers—including tests and WorldState.ts—have been updated to use the named import pattern
import { Simaris } from '@/models', and the barrel export correctly re-exports the named export viaexport * from './Simaris'.lib/models/SortieVariant.ts (2)
1-21: LGTM - Clean refactoring to named exports and path aliases.The import reorganization, switch from default to named export, and path alias usage (
@/supporting) are consistent with the PR's goal of enabling external usage of shared types. The class logic remains unchanged.
58-61: Constructor formatting update looks good.The multi-line parameter formatting improves readability while maintaining the same default behavior (
{ locale: 'en' }).lib/models/Sortie.ts (3)
10-15: Import refactoring aligns with the PR objectives.The switch to path aliases (
@/supporting), type-only imports, and named imports from local modules is consistent with the goal of enabling external usage of shared types. The separation of type imports (usingtypekeyword) from value imports is a good TypeScript practice.
26-30: Class declaration and JSDoc are correctly updated.The
@augments {WorldStateObject}annotation and named export pattern are consistent with the broader refactoring.
66-84: Constructor and variants mapping refactored correctly.The multi-line formatting improves readability. The
optsobject correctly passessortieDataandlocaletoSortieVariantconstructor, maintaining the existing behavior.lib/models/Reward.ts (2)
1-4: Import refactoring to path aliases looks good.The switch to
@/supportingforDependencyandRewardTypesaligns with the PR's objective of enabling external usage of shared types.
31-31: Named export is consistent with the broader refactoring.lib/models/Mission.ts (4)
1-11: Import refactoring is clean and well-organized.The multi-line import from
warframe-worldstate-data/utilities, path alias forDependency, and type-only import forRawRewardfollow the established pattern in this PR.
41-41: Named export is appropriate.The class is now exported as a named export, consistent with the broader refactoring pattern. The previously flagged naming conflict with
Missioninterface inSentientOutpost.tshas been addressed.
166-189: Constructor formatting and reward handling look good.The multi-line signature and conditional
Rewardinstantiation maintain existing behavior with improved readability.
207-227: Array mapping reformats are clean.The multi-line formatting for
advancedSpawners,requiredItems,target, andlevelAurasimproves readability while maintaining the same null-safe mapping logic withlanguageString.lib/models/GlobalUpgrade.ts (4)
1-8: LGTM! Import additions are correct.The addition of
upgradeto the imports fromwarframe-worldstate-data/utilitiesis properly utilized on line 57.
10-10: LGTM! Import path correctly uses the alias.The Dependency import now correctly uses the
@/supportingpath alias, consistent with the broader refactor. The previous issue with the malformed path has been addressed.
12-12: LGTM! WorldStateObject imports are correct.The import correctly uses named imports for both
WorldStateObject(with capital S) andBaseContentObject, consistent with the codebase-wide rename and refactor.
25-25: All imports properly updated to use named exports.The switch from default export to named export is consistent across the codebase. Verification confirms no remaining default imports, and all references (including test files and
WorldState.ts) correctly use the named import syntax via the barrel export atlib/models/index.ts.lib/models/ConclaveChallenge.ts (4)
26-28: LGTM! Consistent rename to WorldStateObject.The JSDoc and class declaration have been correctly updated to reflect the
WorldStateObjectrename, maintaining consistency across the codebase.
79-82: LGTM! Improved type safety with explicit annotations.The constructor signature now includes explicit type annotations and properly handles default values for the dependency parameter. The dual default pattern (destructuring default + parameter default) ensures robust behavior.
103-107: LGTM! Improved destructuring readability.The multi-line destructuring assignment improves code readability while maintaining the same functionality.
11-13: Import path fix is correct and properly configured.The
@/supportingpath alias correctly resolves tolib/supporting/index.ts, which re-exports theDependencytype. The tsconfig path mappings are properly configured, and the import statement will resolve as expected.lib/models/SentientOutpost.ts (6)
1-7: LGTM! Type-only import is a best practice.The import statements are well-structured. The type-only import for
Dependencyis appropriate since it's exclusively used for type annotations in the constructor parameter, which can improve build times and avoid potential circular dependency issues.
30-34: LGTM! Clearer interface naming.Renaming
MissiontoOutpostMissionimproves clarity and reduces naming conflicts, especially now that it's part of the exported public API.
40-41: LGTM! Good use of readonly modifier.Converting to a named export aligns with the PR's goal of standardizing exports. The
readonlymodifier onnodeis excellent defensive programming since the field is initialized once in the constructor and never modified thereafter.
48-62: LGTM! Explicit field declarations improve type safety.Making these field declarations explicit (rather than relying on implicit inference) improves type safety, IDE autocomplete support, and code readability. All field types correctly match their constructor assignments.
68-71: LGTM! Improved readability.The multiline constructor parameter formatting enhances readability without affecting functionality.
30-34: All consumers have been successfully updated for the breaking changes. The named import ofSentientOutpostis correctly used intest/unit/sentientOutpost.spec.tsandlib/models/Tmp.ts, with no remaining default imports. The interface rename fromMissiontoOutpostMissionis properly applied at line 30 and correctly referenced at line 57. The re-export inlib/models/index.tsis configured correctly.lib/models/Fissure.ts (6)
30-32: LGTM!The conversion from default to named export and the base class name correction (
WorldStateObjectwith capital S) align well with the PR objectives to enable external usage of shared types.
88-91: LGTM!The constructor signature is properly typed with the
Dependencyinterface, and the default value{ locale: 'en' }ensures the requiredlocalefield is always available.
121-123: LGTM!The boolean flag initializations correctly use
Boolean()conversion and properly handle both required (ActiveMissionTier) and optional (Hard) fields from the raw data.
96-98: LGTM!The multi-line formatting of these expressions improves readability while preserving the original logic.
Also applies to: 100-102, 110-113
14-14: The TypeScript path alias@/supportingis properly configured intsconfig.jsonand resolves to./lib/supporting/index, which correctly exports theDependencytype. The import is valid.
129-138: No changes needed—non-null assertions are correctly justified by the type contract.The
expiredandetagetters safely use non-null assertions because:
RawFissureinterface explicitly definesExpiryas a required field (not optional)- The
Fissureconstructor parameter is typed asRawFissure, enforcing this contract at compile time- The constructor unconditionally assigns
this.expiry = parseDate(data.Expiry), guaranteeing the property is set- This pattern is consistent with other models like
VoidTraderthat also have required expiry fields and use non-null assertionsThe parent class
WorldStateObjectuses defensive checks because it accepts the genericBaseContentObjectinterface whereExpiryis optional.Fissureis more specific: it requiresExpiryin its input data, so the assertions match the actual data contract. Adding defensive checks would contradict the type system and require changing return types fromstring/booleantostring | undefined/boolean | undefined, breaking the API.Likely an incorrect or invalid review comment.
|
🎉 This PR is included in version 5.2.14 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What did you fix?
export more types, import aliases
Reproduction steps
Evidence/screenshot/link to line
Considerations
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.