Support for post-concatenation plugins about broccoli-css-modules

[dfreeman]

I'm definitely on board with the idea (you're not the first person to hit this), but the final concatenation actually happens over in ember-css-modules — this package only handles the per-module stuff.

I think now that salsify/ember-css-modules#58 has landed, you could run postcss-sprites via ember-cli-postcss on the concatenated output, but having a baked-in, documented postprocess set of plugins would be much nicer.

Would you be up for tackling that in ember-css-modules? It would likely involve conditionally running this tree through something like broccoli-postcss if any postprocess plugins are configured.

[alexlafroscia]

Yup! I wasn't 100% sure what the right level to introduce this would be.

Thanks for the pointer on where to start looking. I'll get a PR together tomorrow.

[alexlafroscia]

So, I have an initial version of this working here:

https://github.com/alexlafroscia/ember-css-modules/tree/add-postprocess-plugin-set

The problem is that it relies on broccoli-postcss, which uses a different syntax for specifying the plugins, which looks like this:

[
  {
    module: require('autoprefixer'),
    options: { ... }
  },
  ...
]

Which means that the syntax, if using before and after and postprocess is kind of mixed

How would you feel about supporting the { module: ... , options ... } syntax in the other two locations, so that it could all be consistent? The alternative is creating a fork of broccoli-postcss and depending on that.

[dfreeman]

I don't totally understand why broccoli-postcss is doing what it's doing with the module/options dance (looks like it's something to do with copying config around?), but it looks like @jasonmit's branch here switches over to broccoli-persistent-filter + postcss, which solves the consistency problem, right?

(Edit: and now I see you've merged that in since I last looked 🙂)

[alexlafroscia]

Yeah! @jasonmit and I work together, so he's been helping me with this 😀

I agree, it's a bit weird that broccoli-postcss differs from the "regular" syntax without a great reason. Not sure why that's necessary, but Jason's plugin seems to be exactly what I'm looking for.

[alexlafroscia]

@dfreeman do you have ideas on how I should set up tests for this new feature?

[dfreeman]

That's an excellent question. We briefly had Nodeland tests for the template transform in ember-css-modules, but ended up converting them to run in the browser when the Glimmer 2 alpha rolled out in order to use the rendering engine that was actually packaged with each version of Ember.

I think explicit tests for the postcss-persistent-filter would be useful to have, which probably means bringing back a Node test runner — the Mocha set up in this repo is probably relatively similar to what you'd want. Beyond that, some kind of smoke test to verify it actually works live (e.g. by adding a postprocess plugin to the dummy app and verifying it gets run) could prevent any careless regressions in the future.

[alexlafroscia]

Cool. I'll add those things a part of my PR. Might be a few days, I'm traveling for the holidays.

[dfreeman]

Sounds good! Feel free to ping me here or on Slack if there's anything I can do to help out — I'm traveling as well so may not be able to respond right away, but I'm super happy to have another dev getting some familiarity with the ECM codebase.