Addon is unable to modify app files using preprocessTree

I use preprocessTree to manipulate app files like this:

const stew = require('broccoli-stew');
const themeName = process.env.EMBER_THEME || 'default';

module.exports = {
  name: require('./package').name,

  preprocessTree(type, tree) {
    if (type === 'css' && themeName !== 'default') {
      tree = stew.rm(tree, `app/styles/config/themes/_current-theme.scss`);

      tree = stew.mv(
        tree,
        `app/styles/config/themes/_${themeName}.scss`,
        `app/styles/config/themes/_current-theme.scss`
      );

      tree = stew.rm(
        tree,
        `${this.app.name}/styles/config/themes/_current-theme.scss`
      );

      tree = stew.mv(
        tree,
        `${this.app.name}/styles/config/themes/_${themeName}.scss`,
        `${this.app.name}/styles/config/themes/_current-theme.scss`
      );

      return stew.debug(tree);
    }

    return tree;
  },
};

This is super straightforward: I remove _current-theme.scss and replace it with another Sass file.

From the debug tree output I can see that the substitution happens successfully.

Yet, the resulting CSS stylesheet does not reflect the substitution.

@simonihmig has figured out that this may be because the addon’s tree gets overwritten with the app tree, so all changes that the addon makes are discarded.

The only exception are new files which don’t exist in the app tree. Those don’t get overwritten. But we can’t rely on a file that does not exist in the app codebase because the IDE is unable to resolve references:

I don’t expect the core team to recognize this as a bug, but from an addon author’s perspective it surely feels as a bug!

How do I make my addon manipulate app files in the build?

PS Why are there two copies of styles in a tree: app/styles/ and my-app-name/styles/?! Which one is the right one?

---

Output from ember version --verbose && npm --version && yarn --version:

ember-cli: 3.28.0
node: 12.14.1
v8: 7.7.299.13-node.16
uv: 1.33.1
zlib: 1.2.11
brotli: 1.0.7
ares: 1.15.0
modules: 72
nghttp2: 1.40.0
napi: 5
llhttp: 2.0.1
http_parser: 2.8.0
openssl: 1.1.1d
cldr: 35.1
icu: 64.2
tz: 2019c
unicode: 12.1
os: linux x64
npm: 7.11.2
yarn: 1.22.4

[simonihmig]

Impressive investigation, thanks @lifeart!

[lolmaus]

@lifeart Thank you for your research and proposed fixes! 🙏

So @lifeart discovered that the root cause of the issue is this line in Sass which makes cwd (current working directory) to always be the first include path. This behaviour is comment-documented here.

Unfortunately, changing that would be severely breaking. Sass relies on that behaviour similar to how Ember CLI relies on that app files always have priority over addons’ app/ files. For this reason, we did not attempt creating a PR or even an issue in Sass.

But this cwd behaviour makes no sense in ember-cli-sass. In ember-cli-sass, cwd should be pointing at the Broccoli tree, not the project codebase. @lifeart has created an upstream issue: https://github.com/simonexmachina/broccoli-sass-source-maps/issues/30

For this reason, the easiest solution could be changing cwd in broccoli-sass-source-maps, rather than creating a custom importer (which must support importing from node_modules/ in addition to the Broccoli tree, which requires extra effort to reimplement).