npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

sane-flags

v0.3.3

Published

A small library for feature flags with explicitness in mind

Downloads

8

Readme

Build Status Coverage Status npm version

Welcome to Sane Flags

Sane flags is a small, focused library to add feature flags to your JavaScript application.

Be Explicit

You should be able to see all the available feature flags.

Because there might be subtle interactions between multiple flags, its key see what is available at any time. This also allows you to better sunset flags.

features.js

To make feature flags easyily discoverable, it is recommended to have a file called something like feature.js. This will hold all of your configuration and should be imported wherever you want to switch features on and off.

Here is an example features.js file:

var saneFlags = require('sane-flags')

var features = saneFlags.wrap({
  flags: {
    dynamic_contact_form: {
      description: 'New contact form that dynamically fills form based on accounts contacts.',
      enabled: false
    }
  }
})

Use cases

Globally turn a feature on or off

When you want to ship a piece of code, without having it really running in production. This makes super sense if you practice continuous integration.

Given the following file containing all your features flags:

var saneFlags = require('sane-flags')

module.exports = saneFlags.wrap({
  flags: {
    dynamic_contact_form: {
      description: 'New contact form that dynamically fills form based on accounts contacts.',
      enabled: false
    }
  }
})

You should be able to import that file and check for flags:

var features = require('./features')

if(features.isEnabled('dynamic_contact_form')) {
  // do something differently...
}

Hook into alternative sources

Maybe you load a configuration from a remote system or the user can switch flags on and off at runtime. For these cases, sane-flags allows you to hook in alternative sources. These sources can be a simple function that gets a flag definition or an object that has a function called isEnabled and takes a flag defintion:

var naiveSource = function(flag) {
  // some way to define if flag should be on
}

var complexSource = {
  isEnabled: function(flag) {
    // some way to define if flag should be on
  }
}
module.exports = saneFlags.wrap({
  flags: {
    dynamic_contact_form: {
      description: 'New contact form that dynamically fills form based on accounts contacts.',
      enabled: false
    }
  },
  sources: [complexSource]
})

Its important that the entire flag object is passed in as an argument. This forces you to define those flags and maintain our core principle: make flags explicit. It also gives you the flexibility to add any attributues to the flag definition that you need to check them against a source.

See the process environment flag source.

Handling different environments

Sometimes you want to have features enabled in lower environments but keep them off in others. For such cases, sane-flags supports an environments key in the configuration and more complex values for enabled. In the spirit of our explicit configuration, you will have to list all available environments and declare which one you are in:

module.exports = saneFlags.wrap({
  flags: {
    dynamic_contact_form: {
      description: 'New contact form that dynamically fills form based on accounts contacts.',
      enabled: {
        dev: true,
        qa: false,
        prod: false
      }
    }
  },
  environments: {
    available: ['dev', 'qa', 'prod'],
    current: process.env.APPLICATION_ENV
  }
})

To be able to ensure consistency, any key underneath enabled must be present in environments.available. Using process.env.APPLICATION_ENV is just an example here.

Consistency and Explicitness

sane-flags is fairly strict in what it expects to see in your configuration. Every flag MUST have a description and an enabled key. To use the per-environment configuration of enabled, you MUST declare the available environments in the environments key. Failure to do so will throw an error when calling wrap(config) to avoid odd behaviour and enforce good practices as far as possible.

Insight

Sane-flags is able to tell you at any point in time what the state of feature flags are. This is valuable for example when booting a service and printing the state of the flags to the console.

Given:

features = saneFlags.wrap({
  flags: {
    dynamic_contact_form: {
      description:
        'The new form that fills in form contacts from the current account',
      enabled: true
    },

    disabled_feature: {
      description: 'The feature we are working on but have disabled',
      enabled: false
    },
    cool_feature: {
      description: 'The feature we are working on but have disabled',
      enabled: {
        dev: true,
        qa: false
      }
    }
  },
  environments: {
    available: ["dev", "qa"],
    current: "qa"
  }
})

Then .state() will print a JSON representation that you could turn into a table:

features.state() // => [{name: 'dynamic_contact_form', enabled: true, description: '...'}, {name: 'disabled_feature', enabled: false, description: '...'}, ... ]

Feature flags and tests

While developing a new feature that is hidden behind a flag, it makes sense to temporarliy switch it on for specific unit tests. sane-flags provides to helper functions that take a closure in which a certain flag can be enabled. Once the closure is complete, sane-flags will disable the feature again to ensure there is no test pollution.

Here are examples directly from the test suite:

Synchronous:

features.enabling('disabled_feature', () => {
  expect(features.isEnabled('disabled_feature')).to.eql(true)
})
expect(features.isEnabled('disabled_feature')).to.eql(false)

Async/Await:

await features.enablingAsync('disabled_feature', async () => {
  wasItEnabled = await someFunctionHere()
})

Should your closure throw an exception then sane-flags will correctly disable the feature again and rethrow the error.

There will be times where you either want to enable/disable combinations of features, possible across multiple tests. For that case there is a testBox inspired by Sinons sandbox. You can enable/disable multiple features on a testBox and reset them all at once:

const box = features.testBox()
box.enable('disabled_feature')
box.disable('enabled_feature')

expect(features.isEnabled('disabled_feature')).to.eql(true)
expect(features.isEnabled('enabled_feature')).to.eql(false)

box.reset()

expect(features.isEnabled('disabled_feature')).to.eql(false)
expect(features.isEnabled('enabled_feature')).to.eql(true)

Extras

Flags from process environment

If you want to enable flags using the process environment, you can hook in the source provided by sane-flags and configure the flags with an extra property environment_flag:

const features = saneFlags.wrap({
  flags: {
    really_cool_feature: {
      description: 'a feature which will be activated with a process variable',
      enabled: false,
      environment_flag: 'THIS_IS_THE_FLAG'
    }
  },
  sources: [saneFlags.sources.processEnvSource]
})

Using a separate key to name the process environment flag to look for ensures your feature names are not coupled to a naming convention from the processes.

Flags will be enabled if the environment varibale has a value of '1' or 'true'.

Making a new release.

Use npx np. That simple.