Strip flagged code from builds.

[rwjblue]

@Cryrivers has been working on ember-feature-flag-solution to spike out how to do the JS and template code stripping. It would be awesome if there could be some collaboration on that....

[Cryrivers]

You can check out https://github.com/Rebelworks/ember-feature-flag-solution. It strips out disabled features from the JS and templates, and also outputs feature flags as SCSS (SASS, Stylus in the future) variables to do conditional compile in SCSS.

It has some limitations and bugs in the htmlbars AST parser. I'm looking forward to your help. :)

[kategengler]

If I'm correctly understanding what you're aiming to do:

• There's some discussion of this feature is in [Feature Request] Conditional Compile #28.
• How does this relate to https://github.com/minichate/ember-cli-conditional-compile and https://github.com/dbazile/ember-cli-comment-defeature?

[rwjblue]

@kategengler - In general, I'd like to consolidate these into a single tool that solves all the things we need here. It doesn't seem that there is a bunch of argument about wanting these features, so if we can come up with a more "blessed" solution I think that is a great idea....

[kategengler]

I think putting the features into a single tool is reasonable, but that striping code should be optional. My use case for this addon provides whether or not a feature is on/off at runtime based on a backend.

[Cryrivers]

hmm, my use case is different from yours. My use case provides a way for my team to work on features at different stages on the same branch, just like the way of Ember Core Team using feature flags in Ember.js. ember-feature-flag-solution strips JavaScript. It strips Handlebars templates and SCSS stylesheets as well.

[kategengler]

@Cryrivers My use case is the same, except for the stripping of code. I very much prefer all development on a single branch. A feature goes to staging or production, and it can be turned on for certain people (developers + QA typically) in those environments. I can see the case for stripping code, but it doesn't make sense for the way I typically work.

[sarus]

Would love to see efforts unified for a single feature flag implementation for ember-cli. I like the idea of being able to strip out unused features when building in environment=production mode but think having it be configurable makes a lot of sense.

[jobackman]

I would also love seeing this feature (as an option)! Could see many useful cases where stripping features or removing files in different production environments would be very useful. 👍 👍

[kategengler]

I'm going to go ahead and say the phrase "PRs welcome"; but it needs to be
configurable.

In the meantime, for anybody looking there are a couple of addons that do
this already:
http://emberobserver.com/addons/ember-cli-conditional-compile
http://emberobserver.com/addons/ember-cli-comment-defeature

On Thu, Mar 10, 2016 at 9:51 AM, Johan Bäckman [email protected]
wrote:

I would also love seeing this feature (as an option)! Could see many
useful cases where stripping features or removing files in different
production environments would be very helpful. [image: 👍] [image: 👍]

—
Reply to this email directly or view it on GitHub
#39 (comment)
.

[kategengler]

Some gotchas/thoughts occurred to me today on this, just documenting them here for if/when this feature is done:

• If stripping code for features, test suites will need to be run against all versions of the build.
• The current provided test helpers are probably not helpful in the case of code stripping.
• How can we feature flag the inclusion of an addon?

[simonihmig]

Just stumbled upon this old issue (5 years, holy cow! 😱)...

In case people are still interested in this (I might be in the future), we now have a much better foundation to build this with @embroider/macros, which seems like a splendid solution for this use case!

The wonderful part here that it already provides all the primitives to add build-time conditionals with dead code elimination, both in JS and HBS-land! So no additional maintenance is required here.

If I don't miss anything (I haven't used this addon yet), the only thing needed is exposing the (static) flags defined in environment.js as setOwnConfig, see https://github.com/embroider-build/embroider/tree/master/packages/macros#setting-configuration-from-an-ember-addon. Obviously changing those at runtime will have no effect with build-time conditions.

Then something like this should work:

{{#if (macroCondition (macroGetConfig "feature-flags" "download-cats"))}}
  <DownloadCat @cat={{this.cat}}>Download</DownloadCat>
{{(if}}

If stripping code for features, test suites will need to be run against all versions of the build.

AFAIK run-time versions of macros will be used (where possible) in dev/test, so no need for different builds. But this need to be confirmed...