types(skyblock): add skill_tree, foraging, shards, attributes, and other API additions to ProfileMember

[Jforjo]

Added all the new API data shown in "skyblock_profile_v2.json" here: HypixelDatabase/HypixelTracking@74e6777
Resolves: #473

[Jforjo]

I put "feat(skyblock)" instead of "types(skyblock)" for most of them... whoops, sorry

[zikeji]

I put "feat(skyblock)" instead of "types(skyblock)" for most of them... whoops, sorry

You can actually do a rebase on that one. An interactive rebase from the starting commit, then tell it you want to update the commit messages. Finally, you can force push those changes to "overwrite" your branch. Force pushing is something that you don't do on the main branches, but is fine on feature branches (generally speaking, YMMV depending on the project and it's requirements).

[zikeji]

You can also update your description to do something like "Resolves #473" to get the automation aspect.

[Jforjo]

I put "feat(skyblock)" instead of "types(skyblock)" for most of them... whoops, sorry

You can actually do a rebase on that one. An interactive rebase from the starting commit, then tell it you want to update the commit messages. Finally, you can force push those changes to "overwrite" your branch. Force pushing is something that you don't do on the main branches, but is fine on feature branches (generally speaking, YMMV depending on the project and it's requirements).

All search results show a CLI solution... and I've never used the CLI for Git before, sorry

[zikeji]

Unfortunately the automate release tooling will bump the minor version if there are feat(ure) commits. In semver, a minor version should introduce a new feature, whereas I don't personally qualify adding more type definitions as a feature. That being said, I can just squash the merge, which I would probably do anyway. I'll want to review this in more depth when I'm more awake, it's 5AM and I've been on side quest after side quest - all because I wanted to update the Vitepress documentation 😓

[zikeji]

In conventional commits fix implies a bugfix. A formatting fix would fall under style. https://gist.github.com/pmutua/7008c22908f89eb8bd21b36e4f92b04f

But like I said - that doesn't exactly matter ultimately, since I'll squash the PR and it'll just get turned into one commit.

[Jforjo]

Unfortunately the automate release tooling will bump the minor version if there are feat(ure) commits. In semver, a minor version should introduce a new feature, whereas I don't personally qualify adding more type definitions as a feature. That being said, I can just squash the merge, which I would probably do anyway. I'll want to review this in more depth when I'm more awake, it's 5AM and I've been on side quest after side quest - all because I wanted to update the Vitepress documentation 😓

np lol
I'll have a look at the previous commits to see what to write next time. Literally first time every contributing to someone elses Github thing

[zikeji]

np lol I'll have a look at the previous commits to see what to write next time. Literally first time every contributing to someone elses Github thing

It's very much the same when working on a team at a company as well - whether you use GitHub, Gitlab, BitBucket, etc. the paradigms can mostly be mapped to eachother. A valuable skill for any SWE!

[Jforjo]

Can this be merged and updated? Could really use the types in my code

[zikeji]

I checked these types against a few live profiles. Most of it verifies exactly, including the full foraging block, active_traps, attributes.stacks, and the garden_chips/SKILL_HUNTING/reaper_peppers_eaten additions.

Four things need fixing before merge - and if you have a profile that contradicts my findings, let me know:

1. skill_trees is the wrong field name. The API sends skill_tree (singular). Any user reading member.skill_trees gets undefined at runtime. It's also slot-based, which the current shape doesn't capture:

"skill_tree": {
  "nodes": { "mining": {...}, "mining_2": {...}, ..."mining_5", "foraging": {...}, ..."foraging_5" },
  "experience": { "mining": 428950, "foraging": 60 },
  "tokens_spent": { "mountain": 15, "mountain_2": 15, "forest_2": 0, ... },
  "selected_ability": { "mining_2": "pickobulus" },
  "last_reset": { "mining": 1783429005097 },
  "selected_skill_tree_slot": { "mining": 2 },
  "refund_ability_free": true,
  "mining":   { "custom_name": "Gemstone Grind" },
  "mining_2": { "custom_name": "Mithril Grind" }
}

The per-node lists you wrote are correct and worth keeping. They just need to sit under a slot-keyed nodes container (mining, mining_2..5, foraging, foraging_2..5), and the type is missing selected_skill_tree_slot and the per-slot { custom_name } metadata objects entirely. experience, tokens_spent, last_reset, and selected_ability are fine as-is since their index signatures already absorb the slotted keys.

2. foraging_core appears to be already stale. The snapshot's flat forests_whispers / forests_whispers_spent / current_daily_effect / current_daily_effect_last_changed are gone from live profiles, replaced by a nested whispers object with per-tier spent under forest/desert. Keep the flat fields for un-migrated profiles, add whispers.

3. active_traps is missing museum?: boolean. Present on every live trap I pulled. hunting_toolkit / hunting_toolkit_index from the snapshot didn't show up on live traps, so those are likely conditional. Leaving them optional is correct.

4. garden_chips.vermin_vaporize is a typo. The snapshot spells it vermin_vaporizer. The index signature keeps it compiling but the named key never matches.

Since I can't commit changes to your own branch, here is a diff capturing my suggested changes:

diff --git a/src/types/Augmented/SkyBlock/ProfileMember.ts b/src/types/Augmented/SkyBlock/ProfileMember.ts
index d598b2f6..e0d5e210 100644
--- a/src/types/Augmented/SkyBlock/ProfileMember.ts
+++ b/src/types/Augmented/SkyBlock/ProfileMember.ts
@@ -157,7 +157,7 @@ export type SkyBlockProfileMember = NonNullable<
     shared_inventory: SkyBlockProfileMemberSharedInventory;
     slayer?: SkyBlockProfileMemberSlayer;
     trophy_fish?: SkyBlockProfileMemberTrophyFish;
-    skill_trees?: SkyBlockProfileMemberSkillTrees;
+    skill_tree?: SkyBlockProfileMemberSkillTree;
     foraging?: SkyBlockProfileMemberForaging;
     foraging_core?: SkyBlockProfileMemberForagingCore;
     shards?: SkyBlockProfileMemberShards;
@@ -273,7 +273,7 @@ export type SkyBlockProfileMemberPlayerData = {
     rarefinder?: number;
     synthesis?: number;
     evergreen?: number;
-    vermin_vaporize?: number;
+    vermin_vaporizer?: number;
     [key: string]: number | undefined;
   };
   reaper_peppers_eaten?: number;
@@ -1109,7 +1109,7 @@ export type SkyBlockProfileMemberRift = {
   [key: string]: unknown;
 };
 
-export type SkyBlockProfileMemberSkillTrees = {
+export type SkyBlockProfileMemberSkillTree = {
   nodes?: {
     mining?: {
       core_of_the_mountain?: number;
@@ -1259,12 +1259,22 @@ export type SkyBlockProfileMemberSkillTrees = {
     } & {
       [key: string]: number | boolean;
     };
+    [key: string]:
+      | {
+          [key: string]: number | boolean;
+        }
+      | undefined;
   };
   selected_ability?: {
     mining?: string;
     foraging?: string;
     [key: string]: string | undefined;
   };
+  selected_skill_tree_slot?: {
+    mining?: number;
+    foraging?: number;
+    [key: string]: number | undefined;
+  };
   tokens_spent?: {
     mountain?: number;
     forest?: number;
@@ -1281,6 +1291,11 @@ export type SkyBlockProfileMemberSkillTrees = {
     [key: string]: number | undefined;
   };
   refund_ability_free?: boolean;
+  [key: `mining${string}` | `foraging${string}`]:
+    | {
+        custom_name?: string;
+      }
+    | undefined;
 };
 
 export type SkyBlockProfileMemberForaging = {
@@ -1396,6 +1411,16 @@ export type SkyBlockProfileMemberForagingCore = {
   forests_whispers_spent?: number;
   current_daily_effect?: string;
   current_daily_effect_last_changed?: number;
+  whispers?: {
+    [key: string]:
+      | {
+          total?: number;
+          [key: `${number}`]: {
+            spent?: number;
+          };
+        }
+      | undefined;
+  };
 };
 
 export type SkyBlockProfileMemberShards = {
@@ -1408,6 +1433,7 @@ export type SkyBlockProfileMemberShards = {
       placed_at?: number;
       shard?: string;
       captured?: boolean;
+      museum?: boolean;
       uuid?: string;
       hunting_toolkit?: boolean;
       hunting_toolkit_index?: number;

[Jforjo]

The main bit that's different on my own profile is

+  selected_skill_tree_slot?: {
+    mining?: number;
+    foraging?: number;
+    [key: string]: number | undefined;
+  };

Which just isn't there and is instead "selected_ability"
Can you confirm that "selected_skill_tree_slot" is in other profiles?

Also, I think I've added all of what you suggested, but a double check would be awesome, thanks

[zikeji]

selected_skill_tree_slot is real - we'll keep it. It's not the same as selected_ability. Yours only has selected_ability because you haven't touched the loadout slots, but it shows up on other profiles and the two sit side by side:

I sampled the user Arka_0's profile data and found: selected_skill_tree_slot: {"foraging": 1}, selected_ability: {"mining": "pickobulus"}

It appears selected_ability is the equipped ability, selected_skill_tree_slot is the active saved loadout. Both stay, both optional. Same reason custom_name (the per-slot name, skill_tree.mining = { custom_name }) needs to come back.

Second, the branch doesn't compile right now. tsc fails on the skill_tree and whispers rewrite, two issues:

• ? isn't valid on an index signature. [key: \mining_${number}`]?:and[key: number]?:` are both syntax errors.
• A template literal that includes a plain literal (`mining` | `mining_${number}`) can't be an index signature parameter at all (TS1337), so the loadout-slot keying doesn't work even with the ? removed.

The pattern that compiles is named keys plus a [key: string] catch-all: keep mining? / foraging? with their node lists, and let [key: string]: {...} | undefined absorb the _2.._5 slots. Same coverage, valid types.

Patch attached that applies on top of your current head and does all of the above. git apply it, then tsc/eslint/prettier are clean. Everything else you did is untouched.

Patch: pr474fixontop.patch

git apply pr474-fix-on-top.patch

[Jforjo]

I have no idea what the issue is, CoPilot says this:

Solution for failing job 97405519409:

The failure is in dependency installation (npm ci), not in your source code lint/tests.
From the job logs, esbuild fails during postinstall with:

Error: spawnSync .../node_modules/esbuild/bin/esbuild ETXTBSY
Node runtime shown in the log: Node.js v26.7.0
This is consistent with your workflow using node-version: latest in the lint job, which can pick an unstable/new runtime and cause install-time binary issues.

Fix
Pin Node to an LTS version in .github/workflows/test.yml instead of latest.

# .github/workflows/test.yml
jobs:
  test_lint:
    runs-on: ubuntu-latest
    if: "! contains(toJSON(github.event.commits.*.message), '[skip ci]')"
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22.x   # was: latest
          cache: npm
      - run: npm ci
      - name: Don't continue if lint fails.
        run: npm run test:lint

Why this works
Avoids Node 26 (seen in the failing job), which triggered the esbuild install error.
Aligns lint/install environment with your existing tested matrix (20.x, 22.x).
Optional hardening
If you want stricter reproducibility across all jobs, define a single workflow env variable and reuse it:

env:
  CI_NODE_VERSION: 22.x

Then use ${{ env.CI_NODE_VERSION }} in setup-node for non-matrix jobs.

[zikeji-s-semantic-releaser]

🎉 This PR is included in version 4.1.11 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀