Other ways to add postcss plugins

[joshwnj]

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?

[joeybaker]

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]

@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:

• 80%: add some extra postcss plugins after the default css-modules transformation
• 15%: add some extra postcss plugins before the default css-modules transformation
• 5%: swap the default css-modules plugins with your own

[joeybaker]

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]

:) 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]

Sure, for postCssModulesScope, I'm passing a custom generateScopedName function.

[joshwnj]

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-modulesify level, rather than having to pass it to a certain postcss plugin?

[joeybaker]

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]

What I'm thinking is more like adding a --customName option 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]

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]

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]

Yea. I like simplicity (and therefore the --customName idea). But I'd think that allowing the default plugins to be configured would be simpler than a custom loader?

[joshwnj]

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-core and then let it be responsible for instructing whatever plugins it uses.

[joeybaker]

Interesting. What does the CLI API look like? --loader npm-module-name?

[joshwnj]

Yeah I thinking something like that. What if we said that for the CLI module-name can be anything that resolves to a module:

• --loader ./src/my-custom-loader
• --loader module-from-npm

If all you wanted was to pass in some custom options to the default loader, ./src/my-custom-loader.js would just require('css-modules-loader-core') and export after applying customizations.

[joeybaker]

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]

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]

👍

[joshwnj]

Closing this now that we've got before and after