API update to SkyBlockProfileMember

[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!

[zikeji]

Why are we removing this? Based on that tracking repo this should still be here:

https://github.com/HypixelDatabase/HypixelTracking/blob/master/API/skyblock_profile_v2.json#L4227C12-L4227C22

[Copilot]

Pull request overview

This pull request updates the SkyBlockProfileMember type definitions to reflect Hypixel's API changes from February 17, 2026. The changes add comprehensive new type definitions for foraging mechanics, skill trees, shards, attributes, and other game features that were recently added to the Hypixel SkyBlock API.

Changes:

• Added 7 new type definitions (SkyBlockProfileMemberSkillTrees, SkyBlockProfileMemberForaging, SkyBlockProfileMemberForagingCore, SkyBlockProfileMemberShards, SkyBlockProfileMemberAttributes, and inline types for temples)
• Refactored harp quest data from quests to foraging.songs.harp structure
• Added new fields to existing types (garden_chips, reaper_peppers_eaten, SKILL_HUNTING, greenhouse crops)

Comments suppressed due to low confidence (1)

src/types/Augmented/SkyBlock/ProfileMember.ts:900

• Removing harp_quest from SkyBlockProfileMemberQuests is a breaking change for any consumers who access member.quests?.harp_quest. While the data is now available at member.foraging?.songs?.harp (which better reflects the API reorganization), this change breaks backward compatibility.

Consider:

1. Documenting this breaking change in the changelog as it requires consumers to update their code paths
2. If following semantic versioning strictly, this would warrant a major version bump
3. Alternatively, you could temporarily maintain both locations (deprecated in quests, canonical in foraging) to provide a migration path

export type SkyBlockProfileMemberQuests = {
  trapper_quest?: {
    last_task_time: number;
    pelt_count?: number;
  };
  [key: string]: unknown;
};

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The tree_gifts type has a conflicting index signature. The first part declares [key: string]: number | undefined, but the second part (after the intersection) adds milestone_tier_claimed which is an object type. This creates a type conflict because the index signature requires all properties to be number | undefined, but milestone_tier_claimed is an object.

To fix this, you should either:

1. Include the object type in the first part's index signature: [key: string]: number | { FIG?: number; MANGROVE?: number; [key: string]: number | undefined } | undefined
2. Or restructure to not use an intersection type if the property names don't overlap with the dynamic keys

Suggested change

	[key: string]: number | undefined;
	} & {
	milestone_tier_claimed?: {
	FIG?: number;
	MANGROVE?: number;
	[key: string]: number | undefined;
	};
	milestone_tier_claimed?: {
	FIG?: number;
	MANGROVE?: number;
	[key: string]: number | undefined;
	};
	[key: string]:
	| number
	| {
	FIG?: number;
	MANGROVE?: number;
	[key: string]: number | undefined;
	}
	| undefined;