Upgrading

← Documentation home · Installation

This guide covers version-to-version changes. For migrating from other libraries, see Comparisons.

---

1.0 → 1.1

No code changes required. RuleBuilder.actions() now accepts wildcard patterns (invoice:*, *:read) without a cast. Existing "invoice:*" as Schema["actions"] still typechecks. evaluate() / permitted() still take concrete schema actions.

→ Wildcard actions

---

0.4 → 1.0

Breaking: the asyncConditions engine option has been removed.

Runtime async detection already handles async conditions — use evaluateAsync(), explainAsync(), or permittedAsync() when rules contain promise-returning conditions.

Before (0.4.x):

const engine = new AccessEngine<MySchema>({
  schema: {} as MySchema,
  asyncConditions: true,
});

await engine.evaluateAsync(user, "invoice:approve", "invoice");

After (1.0.0):

const engine = new AccessEngine<MySchema>({
  schema: {} as MySchema,
});

await engine.evaluateAsync(user, "invoice:approve", "invoice");

If you call sync methods (evaluate, explain, permitted) against async conditions, the engine throws with a message pointing to the async API — no opt-in flag required.

→ AccessEngine reference · Async conditions

---

0.3 → 0.4

Behavior change: async conditions no longer fail silently when used with sync APIs.

• evaluateAsync() and explainAsync() work without the asyncConditions flag
• Calling evaluate() on async conditions throws a clear error (or use *Async methods)
• The asyncConditions option was deprecated in 0.4.0 and removed in 1.0.0

Migration:

1. Replace engine.evaluate(...) with engine.evaluateAsync(...) wherever conditions return promises
2. Remove asyncConditions: true from engine options (required before 1.0.0)

---

Related pages

• API stability policy
• CHANGELOG