@embroider/macros uses previously cached macro condition

[brendenpalmer]

We're seeing issues where a previously cached macro condition is being used as part of the build. For example, ember-engines uses @embroider/macros to have differing logic depending on ember-source version. It's possible for (seemingly) a previously cached macro condition to be used for an incompatible ember-source version. The macro condition that's evaluated as part of the build can be incorrect, and you can get into a state where the macro condition is evaluated correctly without broccoli-persistent-filter's caching enabled (CI=true); however, with broccoli-persistent-filter's caching enabled (regular builds without CI=true) the macro condition is incorrect.

For a simple reproduction I've created a sample repo in OSS: https://github.com/brendenpalmer/embroider-macros-caching-repro.

Steps to reproduce:

1. Clone repo, yarn install
2. Run ember b
3. Open dist/assets/vendor.js; the evaluated macro (specifically the one used in link-to-external) from ember-engines is correct
4. Run yarn add ember-source@3.24.0
5. Run ember b
6. Open dist/assets/vendor.js; the evaluated macro (specifically the one used in link-to-external) from ember-engines is incorrect
7. Run CI=true ember b
8. Open dist/assets/vendor.js; notice that the evaluated macro (specifically the one used in link-to-external) is now different

[thoov]

I was able to reproduce. One minor change to the above steps to reproduce:

4. Run yarn add ember-source@3.24.0
4. Run yarn add ember-source@3.24.1

Some of the dependencySatisfies checks in engines are checking for this version so this version guarantees that all checks will toggle. I will look into this.