Feature flags your build can decide

Stop the domino effect

Your customers never see a feature whose foundation is gone.

New features often rely on older ones. Turning off a foundation feature can leave dependent features in a broken state.

You can make features depend on one another. Before you commit, the toggle lists exactly what will go off. After the change, each feature says why it is off.

createFeatures([
  { key: 'new-checkout', enabled: true },
  { key: 'express-pickup', enabled: true, dependsOn: ['new-checkout'] },
  { key: 'demo-night-booking', enabled: true, dependsOn: ['express-pickup'] },
])

Tests that don't jump

Run clean A/B tests where visitors stay in their assigned group.

Shuffling people between versions mid-test ruins your data and confuses your users.

Visitors who keep their ID keep their variant when you move a two-way split. Only those between the old and new boundary change. You can also pin a specific group to one variant.

{ key: 'cta-color', enabled: true,
  variants: [{ name: 'control', weight: 50 }, { name: 'blue', weight: 50 }],
  rules: [],
}

Launch while you sleep

Set your release date and forget it.

You want to coordinate a big launch without being awake to flip a switch or trigger a deployment.

A rule turns a feature on after the time you choose. Because the decision depends only on the clock, the server and browser always stay in sync.

No flicker on load

Eliminate the jarring visual jump on page load.

Pages that decide flags only in the browser often show a default version for a split second before swapping to the correct one.

The server decides the flags and sends those decisions inside the page. The browser uses them before the first paint and can check the server's decisions against its own copy to report differences.

Built for React

Wrap your app once and any component can ask if a feature is on.

npm install @evanion/feature @evanion/react-feature

import { createFeatures } from '@evanion/feature';
import { FeatureProvider, useFeatureEnabled } from '@evanion/react-feature';

const features = createFeatures([{ key: 'new-checkout', enabled: true }]);

function Checkout() {
  const isNew = useFeatureEnabled('new-checkout');
  return isNew ? <p>New checkout</p> : <p>Old checkout</p>;
}

function App() {
  return (
    <FeatureProvider features={features}>
      <Checkout />
    </FeatureProvider>
  );
}

Questions

What is @evanion/feature?

It is an open source TypeScript library (MIT). You define your rules, rollouts, variants, and dependencies in a file and call it from your API, build, or browser.

Does it need a server of its own?

No. There is no service to call. The file ships with your app, or you can serve it as a plain file to reload it in a running app.

How do anonymous visitors get a stable variant?

Bring your own visitor ID. The library never sets a cookie and never stores which variant anyone got. Signed-in visitors use the account ID. Anonymous visitors use an ID the site already sets, such as a session, cart or analytics ID. If the site has none, you can set a first-party ID cookie yourself, under your own consent rules. Without any ID, the visitor gets the default variant, and percentage rollouts leave them out. To keep a variant across sign-in, use variantBy or stickyVariants.

Does it work with static sites?

Yes. A build decides every flag it has enough information for and writes the answer into the page. Flags that depend on the visitor are decided when the visitor arrives.

Is there React support?

Yes, via @evanion/react-feature. It provides a provider and hooks to access flags anywhere. Server decisions reach the browser so there is no flicker.