[andix]

It's even okay to hardcode them into code (not a config/json file). Depending on the build pipeline this is similar to preprocessor flags, and the code will be removed during build.

It might be enough to test new features with a limited audience (beta build, test deployments for stakeholders/qa).

If done correctly this solution can be easily extended to use a feature flag management tool, or a config file.

PS: removing new features during build/tree-shaking/etc adds some additional security. In some cases even disabled features could pose a security risk. Disabled features are often not perfectly tested yet.

[CRConrad]

> It's even okay to hardcode them into code (not a config/json file).

Yes, as I understood it that was what the article was all about.

[andix]

The article suggests to put them into a config file, and considers it hardcoding. That’s how I understood it at least.

[CRConrad]

Ah, yes indeed, seems I'd misread it; sorry.

(Sheesh, WTF is that guy talking about??? Now not only "feature flag" doesn't mean anything any more, but "hardcoded" doesn't either!)