Repository navigation
Other ways to add postcss plugins #26
Description
Currently if you use the -u option it overrides all postcss plugins, including the css-modules ones, and you have to manually add them back. I can think of some cases when you'd want to do this but it feels like militant-level modularity :)
@joshgillies what would you think about a postcssAfter (and possibly postcssBefore) option, which allows you to add postcss plugins to the transformation either side of the default?
Activity
joeybaker commentedon Aug 6, 2015
Would it be possible to loop through the list of plugins the user provided and add in the rehired ones if they're missing?
joshwnj commentedon Aug 6, 2015
@joeybaker yep we potentially could do that, I'm just questioning whether we'd ever want to remove the default plugins only to re-add them. Do you have a use case in mind?
I want to gear this to be obvious for the most common cases, which at the moment feels like this:
joeybaker commentedon Aug 6, 2015
Heh… well, I guess I fall in the 5%. I wanted to configure the one of the default plugins with my custom options. So, I guess your "hook" based solution would work if there was a way to pass options to the default plugins?
joshwnj commentedon Aug 6, 2015
:) hey, don't take my word for it - I'm just guessing about usage patterns (and going by how I'm using it personally).
Can you give an example of what custom options you're passing? That will give me a better idea of how people are using it.
joeybaker commentedon Aug 6, 2015
Sure, for postCssModulesScope, I'm passing a custom
generateScopedNamefunction.joshwnj commentedon Aug 6, 2015
Cool. I think that particular one will be more like a 50% case, and I'd like a better way to do this too :) Would it work well for you if you could configure the custom name function at the
css-modulesifylevel, rather than having to pass it to a certain postcss plugin?joeybaker commentedon Aug 6, 2015
Totally. Works great as long as none of the other default plugins ever take options :)
Maybe just have the default plugins take options the same way other plugins do? e.g.
options[name]?joshwnj commentedon Aug 7, 2015
What I'm thinking is more like adding a
--customNameoption to css-modulesify (can be a function or a path to a single-function-module). It can figure out which postcss plugin needs to be configured.Would that work for you?
joeybaker commentedon Aug 7, 2015
Yea, that totally makes sense. I'm saying that in addition to that though, it would be nice to have the flexibility to configure all the default plugins the same way we configure plugins we hand in. It's a "nice to have"
joshwnj commentedon Aug 7, 2015
Ah gotcha. I think part of the challenge here is to find the tradeoff between "everything is customizable" and "things just work". For the purpose of css-modulesify I'd rather lean to the latter and not expose too much of the inner machinery. Even though it's made up of a few different postcss plugins, we should really consider them a single thing, because they are all intended to work together in a certain way.
Maybe instead of replacing or customizing individual core postcss plugins we should just allow dropping in a custom loader? Then those that want to can do whatever customizations they like there, without complicating the interface for the 80%.
joeybaker commentedon Aug 7, 2015
Yea. I like simplicity (and therefore the
--customNameidea). But I'd think that allowing the default plugins to be configured would be simpler than a custom loader?joshwnj commentedon Aug 7, 2015
You might be right there :) I'm happy to try out both ways.
The issue I see with customizing core plugins from css-modulesify is that we'd be exposing an API that is 2 levels deep. I'd rather we deal directly with
css-modules-loader-coreand then let it be responsible for instructing whatever plugins it uses.joeybaker commentedon Aug 7, 2015
Interesting. What does the CLI API look like?
--loader npm-module-name?joshwnj commentedon Aug 7, 2015
Yeah I thinking something like that. What if we said that for the CLI
module-namecan be anything that resolves to a module:--loader ./src/my-custom-loader--loader module-from-npmIf all you wanted was to pass in some custom options to the default loader,
./src/my-custom-loader.jswould justrequire('css-modules-loader-core')and export after applying customizations.joeybaker commentedon Aug 7, 2015
Makes sense. I'm not still not convinced it's simpler than allowing users to pass options to the defaults, but I also don't think the two things are mutually exclusive, so WFM!
joshwnj commentedon Aug 7, 2015
Thanks for nutting this out with me! I can definitely see the 2 approaches working in tandem, if we find in future there is a need for both.
joeybaker commentedon Aug 7, 2015
👍
joshwnj commentedon May 30, 2016
Closing this now that we've got
beforeandafter