I built a tiny permission checker so I'd stop writing "if user.role === admin" everywhere

Tejas Kadam — Thu, 30 Jul 2026 18:39:36 +0000

Second small package in a series I started last week (first one was rule-lite, a JSON rule evaluator). This one's about permissions.

Here's the thing about "can this user edit this invoice" - it sounds like a yes/no role question but it almost never is. It's really "can this user edit this invoice, AND do they own it, AND is it under some approval limit." Plain role-based permissions handle the first half fine. Then the second half turns into random if-checks scattered across the codebase, and six months later nobody remembers why that one check exists.

So I made entitlement-lite. Small idea: roles hold permissions like normal, but any permission can also carry an optional condition.

const engine = new EntitlementEngine([
  {
    name: 'contributor',
    permissions: [{
      action: 'edit',
      resource: 'invoice',
      condition: { field: 'resource.ownerId', operator: 'eq', value: 'u1' }
    }]
  }
]);

engine.can(subject, 'edit', 'invoice', { resource: { ownerId: 'u1' } }); // true

No condition on a permission? It's just a normal role check. Condition present? It gets evaluated at request time using rule-lite (the package I put out last week). I didn't want to write a second rule engine just for this, so it reuses the first one.

Also supports wildcards so you're not stuck writing { action: 'view' }, { action: 'edit' }, { action: 'delete' }... for an admin role - { action: '*', resource: '*' } covers it.

It's deliberately not trying to be OPA or Casbin. Those are the right call for big multi-service auth systems. This is for the much more common case: one app, a handful of roles, a few conditions that need actual logic instead of hardcoded ifs.

Repo: https://github.com/tejas821/entitlement-lite
npm: https://www.npmjs.com/package/entitlement-lite

If you've built something similar or have opinions on the API (especially the wildcard matching or how conditions merge into context), I'd like to hear it.

Why I stopped hardcoding conditional logic in enterprise forms (and open-sourced the fix)

Tejas Kadam — Wed, 29 Jul 2026 18:13:10 +0000

Every enterprise app I've worked on eventually hits the same wall: a form or workflow that needs conditional logic — "show field B if A is High," "require C unless D is Approved," "disable E for 30 days after F." The first version is always a few *ngIf*s. Six months later it's an unmaintainable tree of nested conditionals that only the original author fully understands.

I've rebuilt the fix for this three times now, most recently as the rule engine behind a compliance platform's dynamic audit checklists. This time I pulled the core idea out into a standalone package — rule-lite (https://github.com/tejas821/rule-lite) — because the problem is common enough that it shouldn't need reinventing per project.

The core idea

Rules are data, not code:

{
  "all": [
    { "field": "user.age", "operator": "gte", "value": 18 },
    {
      "any": [
        { "field": "user.role", "operator": "eq", "value": "admin" },
        { "field": "user.country", "operator": "eq", "value": "IN" }
      ]
    }
  ]
}

import { RuleEngine } from 'rule-lite';

const engine = new RuleEngine();
engine.evaluate(rule, { user: { age: 25, role: 'guest', country: 'IN' } }); // true

That's the whole API surface: AND/OR/NOT compose to unlimited depth, a dozen built-in operators (eq, gt, in, contains, exists...), and a registerOperator hook for anything domain-specific. Zero runtime dependencies, framework-agnostic — same rule JSON works from an Angular service, a Node backend doing entitlement checks, or a CLI validation script.

Why object-shaped conditions, not a compact DSL

I considered three shapes before settling on this one:

A string DSL ("age >= 18 && country == 'IN'") is the most compact to author, but needs a parser, isn't safely JSON-serializable without escaping, and is hard to validate before evaluation.

A JsonLogic-style array DSL ({"and": [{">=": [{"var": "age"}, 18]}]}) is what JsonLogic itself does — very compact, but genuinely unreadable without the spec open next to it.

Object-shaped conditions ({ field, operator, value }) — what shipped — are more verbose JSON, but self-documenting and trivial to build a form-builder UI around: a select for field, a select for operator, an input for value. That's the actual use case I care about — dynamic forms and business rules that a product or config team, not just engineers, eventually needs to author.

Readability and "can someone configure this without reading a spec" won over raw compactness.

What's next

I'm using this as the first entry in a small "-lite" family of enterprise-focused utility packages — next up is an RBAC/ABAC permission checker that uses rule-lite internally for attribute-based conditions.

If you build dynamic forms, feature flags, or business-rule systems in TypeScript and this shape of problem sounds familiar, I'd genuinely like feedback on the API — especially the operator set and whether the all/any/not composition covers real cases you've hit.

Repo: https://github.com/tejas821/rule-lite
npm: https://www.npmjs.com/package/rule-lite
Full design write-up: https://github.com/tejas821/rule-lite/blob/main/CASE_STUDY.md

DEV Community: Tejas Kadam

I built a tiny permission checker so I'd stop writing "if user.role === admin" everywhere

Why I stopped hardcoding conditional logic in enterprise forms (and open-sourced the fix)

The core idea

Why object-shaped conditions, not a compact DSL

What's next