Allow to use extra postcss plugins after css-modules related plugins

[Strate]

No description provided.

[avanderhoorn]

Any chance we can get this pulled in?

[sokra]

Postcss is internal and should not be exposed. It's a implementation detail.

[avanderhoorn]

Makes sense.

[Strate]

@sokra could you please suggest a solution to apply postcss after css-loader applied?

[longwosion]

I have same situation need to use a custom post-css plugin just after css-loader applied. and I think css-loader should create a hook function to let us to add some extra processes (post-css or more general process) on generated css before plain javascript text.

@Strate You PR is a good patch.

For current version, I must apply all post-css plugins which css-loader used out-of-box, use them in WebPack postcss settings. for example:

module.exports = {
  ...
  module: {
      {
        test: /\.css$/,
        include: /app/,
        loader: 'style-loader!css-loader?importLoaders=1!post-css-loader'
      },
  },
  postcss: [
    require('postcss-modules-local-by-default')({mode:'local'}),
    require("postcss-modules-extract-imports")(),
    require("postcss-modules-scope")({
      generateScopedName: function(localName, path) {
        ...
      }
    }),
   // then add custom postcss
]
}

It's wired, but actually worked.

[sanpoChew]

Are there any alternatives to this? I'm using it because it's the only way for me to use imported values with postcss-inline-svg but am worried about being stuck on an old version. I tried what @longwosion suggested but was having trouble with the generateScopedName function.

[Strate]

@sokra what do you think about splitting this loader into 2 parts: cssmodules part & css-loader part?
With that splitting, full loaders pipeline could looks like that:

loaders: [
  'style-loader',
  'css-loader',
  'postcss-loader?pack=aftermodules',
  'css-modules-loader',
  'postcss-loader?pack=premodules'
]

this solution could made a point to inject postcss plugins after modules without leaking internal implementation from css-loader.

[marbiano]

I would love an answer from @sokra to @Strate questions. This limitation makes useless not only @value, but also :import and :export.

[tomsapps]

I agree with @mbavio I believe this is a feature that css modules should be capable of.

[princed]

I wrote a workaround to overcome this flaw in CSS Modules — https://github.com/princed/postcss-modules-values-replace. I'd love to have some feedback on it.

[ctavan]

@sokra I would be really curious about your feedback on @Strate's suggestion and your opinion on the problem in general.

While I agree that the concrete solution is flawed since it exposes irrelevant implementation details, I still think that there are several viable use cases where one would like to post-process the css which was generated by css-loader. Preprocessing is no problem since one can just add a postcss-loader before css-loader. But post-processing seems to be close to impossible at the moment.

I also think that css-loader is a bit opinionated on the postcss-modules that are being used internally, namely given the minimize option it doesn't really follow the "do only a single task" rule that the webpack docs suggest. It would be really nice if one could disable the builtin cssnano minification (which is possible) and then apply a custom minification afterwards (which is currently not possible).

All in all I think some means to be able to post-process the resulting CSS of css-loader would be a really valuable addition.

In case you do not want to leak the fact that postcss is being used internally to the surface, do you maybe have an idea if and how css post-processing could be achieved outside of the scope of css-loader?