1.0.0-beta.337
What's new
WowSync
1.0.0-beta.337 (2026-07-13)
Full Changelog Previous Releases
- feat(api): add reusable ImportFrom resolver
Add a shared import resolver that can serve this addon and companion
surfaces with one contract for exported names. This lets other addons
or plugins expose the same import behavior without copying the core
lookup logic.
Proxy caching is now scoped by export surface, so like-named exports on
different surfaces cannot return the wrong proxy. Fully exported names
also accept plain tables by falling back when no object getter exists. - refactor(api): drop UI share-dialog command hook
Remove the core-side entry point that loaded the companion UI on demand
and asked it to open a share dialog for import and export. That command
path is gone, so the hook and its public export no longer reach anything
and only invited callers into a dead route.
Dropping it keeps the import surface honest: the UI is still opened
through the existing toggle path, and nothing advertises an import or
export command that the client can no longer act on. - feat(api): add ImportStore to developer exports
- feat(api): expose internals in developer builds
A developer build (X-WowSync-DevMode) now exports a set of internal
objects -- the frame and save tasks, the debugger, snapshots, and the
diff and share helpers -- through the normal import surface, so the
separate test suite can drive them in smoke tests. The flag is stripped
from every release, so a packaged build's import surface stays exactly
the public whitelist.
The flag is also published on the addon's public object, so a companion
addon can gate its own dev-only behaviour on it rather than re-reading
the metadata. The developer-mode login notice is shortened. - feat(apply): defer plugin applies and flag undos
Extend the module apply contract so a plugin gains the async and
undo-aware behavior the built-in modules already have.- A plugin submodule may now defer its apply by returning an AsyncTask;
the plugin pipeline gathers these and reports done only once they
settle, so a plugin whose apply finishes later (after a prompt) keeps
the operation open instead of ending early. The primitive is exposed
to plugins. - Apply now receives whether the write is an undo rather than a
forward apply, so a module that must act differently can tell them
apart. Existing modules ignore it.
- A plugin submodule may now defer its apply by returning an AsyncTask;
- refactor(actionbars): call C_ActionBar page APIs
Replace debug-state reads of bonus bar offset and current action bar
page with C_ActionBar namespace methods instead of deprecated global
wrappers. Behavior stays the same because the wrappers forward to the
same calls, but this keeps the module aligned with current API and
avoids relying on deprecated action bar globals. - fix(talents): import all loadouts one at a time
C_ClassTalents.ImportLoadout creates its config asynchronously, and a
second import fired before the first finishes is dropped -- so only the
first loadout of a snapshot was ever created. Import them strictly one
at a time, driven by a state machine that waits for each created
config before starting the next.- Capture only the active spec's loadouts: a snapshot can only be
restored into the spec it was taken in, since ImportLoadout is
spec-locked. - After importing, re-select the loadout (or Starter Build) that was
active when the snapshot was saved, waiting for a just-created config
to report populated before loading it. Previously the user had to
open the Talent UI and pick a loadout by hand. - Apply returns an AsyncTask that settles once the imports and
activation finish, so the action stays in progress for its whole
async duration.
- Capture only the active spec's loadouts: a snapshot can only be
- fix(actionbars): stop apply erroring on a nil API
C_SpellBook.IsPlayerSpell does not exist, so the known-spell guard
while placing a spell action called a nil value and aborted the whole
action bars apply. Use IsSpellKnownOrInSpellBook, the real check. - feat(apply): make module apply asynchronous-aware
A module's apply can finish after Apply returns -- completing on a
later game event rather than inline. Let the pipeline wait for the real
end instead of assuming every apply is synchronous.- Add AsyncTask, a minimal promise-like completion handle with no
scheduler, frames or coroutines: resolve, reject, on-settled, and a
combinator that settles once every gathered task has. - Apply may now return an AsyncTask; the registry gathers the returned
tasks into one combined task alongside the results, already resolved
when nothing ran asynchronously. - Snapshot apply and undo fire their finished event only once that
combined task settles, so an action stays in progress for its whole
duration, async tail included. A synchronous apply settles at once
and still fires immediately. - Add SnapshotActionMonitor: collapse save, apply and undo into one
busy state and re-broadcast coarse started and finished events so
consumers can gate on "a snapshot action is running".
- Add AsyncTask, a minimal promise-like completion handle with no
All Relations
- All Relations
- Embedded Library
- Optional Dependency
- Required Dependency
- Tool
- Incompatible
- Include

