Kaysser Kayyali d038eb8c67 v0.3.0: rename module id hax-hooks-lib -> foundry-hooks-lib
User callout: 'Hax' is Kaysser's nickname. The module id should
not use it. Rename the Foundry module id from 'hax-hooks-lib' to
'foundry-hooks-lib'. Gitea repo name stays as 'hooks-lib' (kept
for the user-facing URL); the Gitea manifest URL is unchanged.

**Scope of rename:**
- module.json: id, title, version (0.2.0 -> 0.3.0), download URL
- package.json: name
- README.md, HOOK_CONTRACT.md, LICENSE: branding text
- All 6 production JS files: MODULE_ID constant + comments
- 4 active test files: console.log strings + test descriptions
- Rename of release zips in git: hooks-lib-X.Y.Z.zip ->
  foundry-hooks-lib-X.Y.Z.zip (preserves the v0.1.0 and v0.2.0
  zips as historical artifacts; the v0.3.0 zip is the new
  release artifact)
- .gitignore: glob + un-ignore lines updated to match

**Out of scope (deliberate):**
- Gitea repo name 'kaykayyali/hooks-lib' stays. Per the user's
  direction, only the module id is renamed; the Gitea URL path
  is preserved for the existing 'url', 'manifest', 'download'
  fields.
- scripts/_archive/v0.1.0/*: historical v0.1.0 code is left
  as-is. Those files tested 'hax-hooks-lib v0.1.0'; rewriting
  the history would be misleading.
- tests/_archive_v0.1.0_*.mjs: same reason, left untouched.
- .hermes/plans/* session-historian plans that reference
  'Hax's Tools split': session artifact, not a release asset.

**Verification:** 554/554 smoke assertions pass, 6/6 perf
assertions pass, median 0.0004ms/fire (well under 0.1ms
budget). No logic change; rename is string-only.

**Consumer action required:** battle-focus and its-achievable
both declare 'relationships.requires' pointing to
'hax-hooks-lib'. The next commits on those repos will update
their relationships to 'foundry-hooks-lib' + bump their
versions. Foundry instances with v0.2.0 of the old id
installed will need to be reinstalled as v0.3.0 of the new
id.
2026-06-20 16:53:37 -04:00

Foundry Hooks Lib (foundry-hooks-lib)

Foundry VTT module (id: foundry-hooks-lib) that turns Foundry's hook soup (dnd5e, combat, token updates, canvas/UI) into a clean, normalized event stream. Library-only — no UI, no settings, no chat output. Designed to be consumed by any module that wants Foundry events in a stable shape.

Part of the Foundry module split (battle-focus + its-achievable + this lib). Consumers today: battle-focus (encounter + journal + summary) and its-achievable (achievements, rewards, wall, HUD). System-specific knowledge (dnd5e rolls, PF2e, etc.) lives in separate adapter repos that declare Foundry + system version ranges they support.

v0.3.0 — module id renamed (hax-hooks-lib → foundry-hooks-lib)

v0.2.0 is a complete rewrite. v0.1.0 shipped as a curated-event catalog (a list of hand-written handlers for 18 specific Foundry events). v0.2.0 replaces that with a generic facade:

  • Subscribes to every relevant Foundry hook (combat lifecycle, all document CRUD, canvas/UI, dnd5e v2 roll hooks, etc.).
  • Emits a uniform envelope — {ts, hook, args} — with no domain interpretation.
  • Consumers write queries against the envelope. "When bob takes damage" is a consumer-side query, not a hook name the library knows about.
  • System-specific derived events (e.g. "dnd5e attack roll") live in separate adapter repos. Adapters register a manifest with Foundry + system version ranges; the library evaluates at ready and loads matching adapters.

Why this shape: Foundry's hook names and arities change between versions. The library absorbs that churn (§9 + §10 of the contract) so consumers don't have to rewrite every Foundry upgrade.

Status

v0.2.0 — generic facade per docs/HOOK_CONTRACT.md. Smoke test: 554/554 assertions. Perf test: median 0.0003ms/fire (333× under the 0.1ms budget).

Envelope shape

Every fire produces exactly one envelope:

{
  ts:   1719000000000,    // epoch ms when Foundry fired
  hook: "updateActor",    // the Foundry hook name (normalized; see §9)
  args: [doc, change, options, userId]  // positional args, verbatim
}

That's it. No kind, no normalized fields, no consumer metadata. Consumers that want {kind, actorId, delta} build that themselves from args. This is intentional: the library is the boundary that absorbs Foundry version churn.

Public API (on game.modules.get("foundry-hooks-lib").api)

import { subscribe, subscribeMany, subscribeAll } from
  game.modules.get("foundry-hooks-lib").api;

// Single hook:
const unsub = subscribe("updateActor", (envelope) => {
  const [actor, change] = envelope.args;
  // ...
});

// Batch subscribe (atomic):
subscribeMany({
  updateActor: handleActorUpdate,
  createToken: handleTokenCreate,
});

// Every hook (for audit logs):
subscribeAll((envelope) => log(envelope));

// One-shot cleanup:
unsub();   // or unsubscribeAll() to purge everything

System adapters

A system adapter is a separate Foundry module. At its init, it calls:

hooksLib.api.registerSystemAdapter({
  id: "foundry-hooks-dnd5e",
  moduleId: "foundry-hooks-dnd5e",
  system: { id: "dnd5e", versions: ">=5.2.0 <5.3.0" },
  foundryVersions: ">=13 <15",
  factory: () => [ /* derived-event registrations */ ],
});

The library evaluates the manifest against game.system.id + version and game.version at ready. Matching adapter factories are called once. Non-matching adapters log a warning naming the version mismatch (or silently skip for non-matching system).

Subscribed hook set (v0.2.0)

Lifecycle, document CRUD (Actor/Token/Item/Scene/JournalEntry/ ActiveEffect/Combat/Combatant), combat lifecycle, chat & rolls (incl. dnd5e v2 roll hooks), canvas/scene/UI (canvasInit/Ready/Pan, controlToken, hoverToken, targetToken, lighting/sightRefresh, collapseSidebar, changeSidebarTab, getSceneControlButtons, renderChatMessage, renderChatInput, renderJournalPageSheet, rtcSettingsChanged), and more. Full list: scripts/internal/registered-hooks.js.

Error containment

If a consumer callback throws, the library catches it, logs via console.error with the [foundry-hooks-lib] prefix and the hook name, and continues dispatching to subsequent callbacks. Errors never propagate to Foundry's hook chain.

Tests

npm test             # 554 assertions in ~0.4s, no Foundry needed
npm run test:perf    # median 0.0003ms/fire, heap delta check

See tests/PLAN.md for what we test and what we don't. The Foundry-load test (Playwright against a live Foundry) is deferred to when a real consumer (battle-focus) migrates and exercises it.

Architecture notes

  • One envelope shape, one dispatcher. Adding a new Foundry hook is one entry in scripts/internal/registered-hooks.js. No new file.
  • System adapters are repos, not files. Each system's derived knowledge is its own module with its own version cadence.
  • Anti-corruption (§9-§10): library subscribes to BOTH v13 and v14 hook names where applicable; consumers see stable envelope names.
  • Async dispatch (microtask) by default. pre-* + combat* + applyActiveEffect + get*Context dispatch sync because their return values matter.

Dependencies

None. Library-only; system adapters depend on this, not the other way around.

Maintained by Kaysser Taylor + Hermes

Description
Hax's Tools � Foundry VTT hook normalization library (battle-focus slice 1)
Readme 464 KiB
Languages
JavaScript 100%