Not working with other css tools (Less) about ember-css-modules

[dfreeman]

@ynnoj You shouldn't have any need for ember-cli-postcss with this—you can pass PostCSS plugins directly to this addon to be executed as part of the modules pipeline. Is there something specific you're looking to do with ember-cli-postcss that you can't accomplish that way?

[ynnoj]

@dfreeman Awesome! I did not realise that. I'll adjust the project build setup and see how it works out.

Thanks!

[dfreeman]

The fact that app.less gets lost definitely looks like a bug on this end. Assuming that's something simple (and I suspect it is), you should be able to get ember-css-modules and ember-cli-less working pretty smoothly in isolation from one another once that's fixed.

Actually using the two in concert is going to be a harder problem (partially discussed in #4). In particular with Less, the @value foo: bar; syntax conflicts with Less's @foo: bar; variables, which will likely limit what's possible.

Regardless, losing the .less file is something we should be able to fix—I'll see if I can track that down before the next release goes out.

[ynnoj]

I'm encountering the same issue, but when using ember-cli-postcss.

[jasonmit]

I haven't really gotten to the bottom of this yet, but it looks like the toTree function within ember-cli-less never gets called when ember-css-modules is added to the problem.

I'll report back if I can figure out why...

[jasonmit]

I found the issue, PR incoming soon.

https://github.com/salsify/ember-css-modules/blob/master/lib/output-styles-preprocessor.js#L25

Should be a merge tree consisting of inputNode and the returned tree from this.dynamicHeaderConcat(concatOptions). But not returning it, it seems to break other plugins registered on the css registry.

I'll patch this because in our example, we are using postcss along side, and ordered in front of ember-css-modules, to do a lot of other preprocessing steps. Like @dfreeman this won't make this addon work with something like ember-cli-less but will likely cause it to fail parsing a less file versus the less file not even making it to the parser.

[dfreeman]

@jasonmit thanks for investigating — I got as far as the dropped inputNode, but came to the same conclusion around it still being difficult to get multiple CSS preprocessors to live nicely together.

I have a couple other ideas I'll try playing with when I next have some time to devote to squashing bugs here.

[jasonmit]

Yeah, the thing about merging the tree I found that it will write the original styles tree, in it's entirety, to the dist (not just the concatted app.css). This required then to do some postProcessTree filtering to make sure that folder structure gets filtered out.

The core of the issue is that ember-cli doesn't support really two preprocessors on the same tree-type without hacks in place, such as:

https://github.com/jasonmit/______ember-css-example/blob/master/lib/postcss-addon/index.js#L13-L21

Have you explored moving this logic to a treeForStyles hook instead of registering a preprocessor for the type js this way other addons might be able to mutate that tree before ember-css-modules does. The challenge I guess is figuring out how to write to the app tree within the treeForStyles hook.

This is really impressive work, great addon.

[dfreeman]

@jasonmit The story of this addon is mostly one of plumbing trees between places that Ember CLI doesn't really expect them to go 😉 .

@antulik I think I've got a reasonable fix on this branch, with a demo app making use of it. It allows you to specify an intermediateOutputPath for the concatenated modules so that your preprocessor of choice can import that and then do whatever else it wants in order to produce the final output.

That branch still needs documentation and testing, but can you take a look and see if it seems like it'll solve your problem?

[dfreeman]

This is now possible in 0.4.0, which was just released — see the README for details.