feat: parse nightwave acts #778
Conversation
WalkthroughAdds Nightwave Challenge support: new item type, scraper inclusion, parser/build image-name and manifest-lookup adjustments, hash helper refactor, large cache & warning data additions, and TypeScript type updates. Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Areas to focus during review:
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
|
oh whoops, Build check is running into cloudflare |
SlayerOrnstein
force-pushed
the
feat-nightwave-acts
branch
from
cbbb671 to
68503ba
Compare
SlayerOrnstein
force-pushed
the
feat-nightwave-acts
branch
from
68503ba to
87d66cd
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
build/build.mjs (1)
237-237: Potential null reference for Nightwave Act items.For Nightwave Act items, the
imageBaselookup at line 229 uses the modifieduniqueName(digits stripped), but this line still usesitem.uniqueName(original). If the manifest doesn't contain an entry with the original uniqueName,manifest.find(...)returnsundefined, and accessing.fileTimethrows.Consider using the modified
uniqueNamevariable consistently, or guard against undefined:- const hash = manifest.find((i) => i.uniqueName === item.uniqueName).fileTime || imageHash[1] || undefined; + const hash = manifest.find((i) => i.uniqueName === uniqueName)?.fileTime || imageHash[1] || undefined;Or for clarity, reuse
imageBase:- const hash = manifest.find((i) => i.uniqueName === item.uniqueName).fileTime || imageHash[1] || undefined; + const hash = imageBase.fileTime || imageHash[1] || undefined;
🧹 Nitpick comments (1)
build/parser.mjs (1)
552-552: Consider hoisting thehashhelper outsideaddImageName.The
hashfunction is recreated on every call toaddImageName. While the performance impact is minimal, moving it to module scope (neartitleat line 27) would avoid redundant function allocations during the parsing loop.+const hash = (str) => createHash('sha256').update(str).digest('hex'); + /** * Titlecase a stringThen remove line 552 inside
addImageName.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
build/build.mjs(1 hunks)build/parser.mjs(3 hunks)build/scraper.mjs(2 hunks)config/itemTypes.json(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (3)
build/scraper.mjs (1)
build/network.mjs (2)
getJSON(22-29)getJSON(22-29)
build/build.mjs (2)
build/parser.mjs (2)
item(159-159)i(311-311)build/scraper.mjs (2)
manifest(170-170)i(140-140)
build/parser.mjs (1)
build/build.mjs (3)
hash(237-237)item(84-84)item(224-224)
⏰ 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: Build
🔇 Additional comments (3)
config/itemTypes.json (1)
1060-1064: LGTM!The new "Nightwave Act" item type entry is correctly structured and appropriately placed at the end of the array. The simple string match on
"Challenges/Seasons"will correctly identify Nightwave challenge items.build/scraper.mjs (2)
96-98: Add a guard forExportNightwaveto prevent runtime errors.If the API response doesn't include
ExportNightwaveorchallenges, this will throw. Other similar blocks (like line 100 forExportRailjackWeapons) don't guard either, but Nightwave data may be more volatile.Verify that
ExportNightwave.challengesis always present in the SortieRewards endpoint response. If uncertain, consider adding a defensive check:if (category === 'SortieRewards') { - data.push(...raw.ExportNightwave.challenges); + if (raw.ExportNightwave?.challenges) { + data.push(...raw.ExportNightwave.challenges); + } }
185-188: LGTM!The data source change to GitHub's raw URL for the WFCD/warframe-drop-data repository is a reasonable alternative to avoid Cloudflare issues with drops.warframestat.us. Both sources are maintained by WFCD.
Was meant to only be my machine to bypass cloudflare while I was testing. Was not supposed to be commited
nightwave stuff might need some changes to how their parsed in pathlogs instead of here
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
build/parser.mjs(5 hunks)config/itemTypes.json(1 hunks)index.d.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- config/itemTypes.json
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-items PR: 778
File: build/parser.mjs:568-574
Timestamp: 2025-11-28T01:41:19.901Z
Learning: In the WFCD/warframe-items repository, for Nightwave Act processing, the regex difference between `build/parser.mjs` (using `/[0-9]{1,3}$/` with anchor) and `build/build.mjs` (using `/[0-9]{1,3}/` without anchor) is intentional and serves different purposes in each file.
📚 Learning: 2025-11-28T01:41:19.901Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-items PR: 778
File: build/parser.mjs:568-574
Timestamp: 2025-11-28T01:41:19.901Z
Learning: In the WFCD/warframe-items repository, for Nightwave Act processing, the regex difference between `build/parser.mjs` (using `/[0-9]{1,3}$/` with anchor) and `build/build.mjs` (using `/[0-9]{1,3}/` without anchor) is intentional and serves different purposes in each file.
Applied to files:
build/parser.mjs
📚 Learning: 2024-12-03T23:47:24.677Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-items PR: 663
File: config/masterableCategories.json:1-2
Timestamp: 2024-12-03T23:47:24.677Z
Learning: In the 'warframe-items' repository, when suggesting changes to regex patterns in 'config/masterableCategories.json', ensure that added patterns only include items relevant to the current PR context, and avoid adding items not present in the context.
Applied to files:
build/parser.mjs
🪛 GitHub Actions: Pull Request Checks
build/parser.mjs
[error] 758-758: prettier/prettier: Insert ·
🪛 GitHub Check: Lint
build/parser.mjs
[failure] 758-758:
Insert ·
[failure] 848-848:
Expected '===' and instead saw '=='
🔇 Additional comments (6)
index.d.ts (3)
96-97: LGTM!The
NightwaveChallengetype is correctly added to theItemunion, enabling proper type discrimination for Nightwave items.
189-192: LGTM!The
NightwaveChallengeinterface is well-defined with appropriate fields for challenge tracking (requiredandstanding). It correctly extendsMinimalItem, consistent with other specialized item types in the codebase.
854-854: LGTM!The
'Nightwave Challenge'type literal is correctly added to theTypeunion, enabling proper type checking for Nightwave items.build/parser.mjs (3)
552-552: LGTM!The hash function refactor from precomputed digests to an on-demand functional helper is clean and maintains the same SHA-256 hashing behavior while improving flexibility.
568-574: LGTM!The Nightwave Challenge special-case logic correctly handles image naming by:
- Stripping trailing Roman numerals from the display name
- Sterilizing the uniqueName to group similar challenges
- Generating a short hash-based identifier for uniqueness
The early return appropriately bypasses standard image-name processing for these items. Based on learnings, the regex pattern used here is intentionally different from other files and serves a specific purpose.
613-613: LGTM!The hash usage is correctly updated to use the new functional helper, maintaining consistency with the refactored approach.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
build/parser.mjs (1)
552-618: Nightwave imageName hashing and helper extraction look solid; only tiny optional nitThe
hashhelper and Nightwave-specific imageName logic (Roman numeral stripping + trailing-digit sanitization + 10‑char SHA‑256 suffix) are consistent and should give stable, deduped filenames without interfering with the generic component/relic logic thanks to the earlyreturn. If you expect to reuse this hashing elsewhere, you could optionally hoisthash(and evenencode) out ofaddImageNameto avoid recreating them per call, but that’s not required. Not re‑raising any regex alignment concerns withbuild.mjs, since the differing digit‑stripping regexes are already confirmed to be intentional.
Based on learnings, the current regex usage is intentional.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
build/parser.mjs(5 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-items PR: 778
File: build/parser.mjs:568-574
Timestamp: 2025-11-28T01:41:19.901Z
Learning: In the WFCD/warframe-items repository, for Nightwave Act processing, the regex difference between `build/parser.mjs` (using `/[0-9]{1,3}$/` with anchor) and `build/build.mjs` (using `/[0-9]{1,3}/` without anchor) is intentional and serves different purposes in each file.
📚 Learning: 2025-11-28T01:41:19.901Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-items PR: 778
File: build/parser.mjs:568-574
Timestamp: 2025-11-28T01:41:19.901Z
Learning: In the WFCD/warframe-items repository, for Nightwave Act processing, the regex difference between `build/parser.mjs` (using `/[0-9]{1,3}$/` with anchor) and `build/build.mjs` (using `/[0-9]{1,3}/` without anchor) is intentional and serves different purposes in each file.
Applied to files:
build/parser.mjs
📚 Learning: 2024-12-03T23:47:24.677Z
Learnt from: SlayerOrnstein
Repo: WFCD/warframe-items PR: 663
File: config/masterableCategories.json:1-2
Timestamp: 2024-12-03T23:47:24.677Z
Learning: In the 'warframe-items' repository, when suggesting changes to regex patterns in 'config/masterableCategories.json', ensure that added patterns only include items relevant to the current PR context, and avoid adding items not present in the context.
Applied to files:
build/parser.mjs
⏰ 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: Build
🔇 Additional comments (2)
build/parser.mjs (2)
752-812: Nightwave guard inaddDropRatematches the feature intentEarly‑returning for
item.type === 'Nightwave Challenge'cleanly keeps Nightwave acts out of the general drop‑table machinery and previous‑build migration logic, which aligns with them not being conventional droppable items. No issues here.
846-865: Skipping patchlogs for Nightwave challenges is reasonableExtending the existing “no patchlogs for components” guard to also cover
Nightwave Challengeitems avoids unnecessary patchlog lookups for these synthetic tasks and keeps their surface minimal. The condition is clear and low‑risk.
2 participants
What did you fix?
Merges
ExportNightwaveinto sortie rewards to pull in nightwave acts and imagesReproduction steps
Evidence/screenshot/link to line
Considerations
Summary by CodeRabbit
New Features
Data Updates
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.