HTMLbars cache isn't busted on rebuilds

[oscarni]

I believe the cache issue (#21)
is still present.

@minichate looks like I've been celebrating a bit to early when I made this PR #25 a month ago.
Looks like the newer versions of ember were actually disabled caching when throwing the warning about missing caching strategies. So the "fix" in the PR actually did nothing except reinstating the issue.

I believe we were all testing this "fix" when other plugins were also incompatible, resulting in no cache. I just encountered that the caching issue is still an issue when I managed to remove all AST-warnings.

After taking a closer look at ember-cli-htmlbars it looks like the new AST-caching strategy (specifying a baseDir) only lets htmlbars know where to look for changes and makes sure cache is busted when file changes are made in an addon's directory. There is no support for cache busting based on options yet, which is what's needed here.

There is are discussions for making ember-cli-htmlbars the same type of cacheKeys as this module has babel/broccoli-babel-transpiler#89, but until then it looks like there are only "hacky" ways for this addon to actually bust the template cache.

• One way would be to save the current feature-flag options and write them to a file inside this addon directory on each build. This would let the directory based caching strategy know it needs to bust cache, but it feels a bit of a hac, although would solve the issue for now.
• Another solution would be to revert my PR, thus enabling the annoying warning about AST-caching strategy and again force cache busting on every rebuild.

Just wanted to let you know about my findings and thanks for a great plugin!

[jobackman]

I'll chime in since I was also part in looking into this. I opened a PR to ember-cli-htmlbars which adds the cacheKey option for cache-busting that @oscarni speaks of.

If they accept it we can add the cacheKey option with featureFlags as value and the cache problem should be fixed.

// index.js
target.registry.add(
  'htmlbars-ast-plugin', {
    name: 'conditional-compile-template',
    plugin: TemplateCompiler(config.featureFlags),
    baseDir: function() {
      return __dirname;
    },
    cacheKey: function() {
      return config.featureFlags;        
    }
  }
);

[tehmaestro]

What's the best way of busting the cache right now? How are you guys doing it?

Edit: I followed jobackman's lead and his method works. Thank you so much!

[Duder-onomy]

Just an update from my side.
Blowing out and re-building node_modules does not reliably work. I have to delete and re-clone my repo every time I want to change the flag in a reliable way.

[jobackman]

Since I'm not sure if they'll accept my suggestion over at the htmlbars repo or even seen it, I've set my package.json to use ember-cli-conditional-compile from a before #25 was merged rather than having a forked version of htmlbars. #25 resolved a deprecation warning coming from htmlbars, which if it is triggered always busts the cache. So to reliably bust my htmlbars cache I updated my package.json to a use a commit from before the bugfix was merged:

"ember-cli-conditional-compile": "git://github.com/minichate/ember-cli-conditional-compile.git#6a50e98fd3dd0d9192e70562b76649643dfc70b3",

So on building I'll always get the cache busted since I'm not supplying a cache strategy

This has worked reliably for me so far.

[minichate]

I think this is resolved now; let me know if it reappears and I'll take another look!