How to handle multiple loaders with different plugins using postcss.config.js?

[bebraw]

Hi,

I have the full issue here. The problem is that the user needs to run different plugins on different loaders. One should get only stylelint and so on.

I can see you can return a function from postcss.config.js, but then the problem becomes how to tell the loader definitions apart. Webpack 2 doesn't allow setting custom fields per a loader definition. Maybe we could piggyback on options, though?

Any ideas on how to handle this?

[ai]

I will add config option on this week.

[bebraw]

Ok, cool. 👍

[michael-ciniawsky]

@bebraw What context would be needed ? ctx.webpack is on the ctx by default, it's just not 'harmonised' with other build tool integrations, due to time leakings of mine atm. (ctx.env, ctx.ext, ctx.dir etc.)

ctx.env = process.env.NODE_ENV ( )

ctx.dir = dirname(webpack.resourcePath) (:shipit: as ctx.webpack)
ctx.ext = webpack.resourcePath.endsWith('.sss') (:shipit: as ctx.webpack)

Anything else that could be shimmed from ctx.webpack to its own prop? Note that build tool specific ctx should be always on it's own ctx['webpack'], but things like dir, ext, file || filename etc can be harmonised between them.

@ai Implementation proposal for config 💪 😛

webpack.config.js

{
  test: /\.css/,
  use: [ 
    { loader: 'css-loader', options: { importLoaders: 1 } }, 
    { 
       loader: 'postcss-loader', 
      // options.config is -1 in terms of code style/cide cleaness, 
      // maybe better solution can be found :)
       options: { 
         config: { file: 'alternative/path/to/postcss.config.js', ctx: { modules: true } } 
       }
    }
  ]
}

postcss.config.js

module.exports = (ctx) => ({
    parser: ctx.ext === '.sss' ? 'sugarss' : false
    plugins: {
      'postcss-import': { root: ctx.dir },
      'postcss-modules': ctx.modules ? {} : false
      'postcss-whatever': ctx.whatever ? {...ctx.foo} : {..ctx.bar}
    }
})

Besides that, since webpack core member is present, I like to propose merging postcss-loader/css-loader 😛 . css-loader uses postcss for CSS Modules under the hood anyways

webpack.config.js

{
  test: /\.css/,
  use: [ 
   // via postcss.config.js
    { 
       loader: 'css-loader', 
       options: { 
         config: { file: 'alternative/path/to/postcss.config.js', ctx: { modules: true } }
       }
    },
   // or inline 
    { 
       loader: 'css-loader', 
       options: { 
         parser: 'sugarss',
         modules: true,
         plugins: () => [...plugins]
       }
    }
  ]
}

And by the way the same would apply to html-loader+ posthtml-loader + posthtml.config.js :)

[ai]

Do we need a ctx magic if we will have different config paths? But I am OK with both syntax: config: "path" and config: "path", ctx: { … }

[bebraw]

To refer to survivejs/webpack-book#129, in that case it would be enough if you could perform a check against enforce option, right @Velenir?

I'm sure this is not the only use case, though. It would be good to know how people are actually using postcss-loader in their projects now.

Besides that, since webpack core member is present, I like to propose merging postcss-loader/css-loader 😛 . css-loader uses postcss for CSS Modules under the hood anyways

My understanding is that we actually might want to go to the opposite direction in the future as it feels like the current css-loader does too much. This would mean pushing the CSS Modules functionality out of it entirely and possibly handling it through postcss-loader.

That said, I would love to see a strong design for CSS pipeline as it feels like a sore point at the moment. Simplifying css-loader would just push the problem elsewhere.

I have a feeling we might need some kind of concept of context in the design in order to eliminate weirdness like importLoaders index. I guess at minimum this might mean a separate option for css-loader where you specify which loaders it should use to parse on @import (loader definition within loader definition).

Minification is another interesting point, but that goes beyond this issue so I won't expand on that. The things I mentioned above are more of longer term concerns.

[Velenir]

Yes, in case of linting in a preloader it would be enough to check for enforce. But there may be cases of postcss-loader in different arbitrary positions in the loaders' chain, so some kind of loader specialization would still be necessary.

Also, currently in the context a preloader is simply appended to the loaders array with nothing to distinguish it from a normal first loader -- both would be first in the chain (first from the right in the array) -- no enforce property, no nothing. So loaderIndex === loaders.length -1 doesn't guarantee that the current loader is pre.

[michael-ciniawsky]

@ai Yes and no 😛 . If it's clear separation of concerns like e.g linting .scss files with postcss-loader and stylelint => use separate postcss.config.js in .scss directory

It's not possible to override plugin options via context, if required e.g ctx.modules

postcss.config.js

module.exports = (ctx) => ({
   parser: 'sugarss'
   plugins: {
     'postcss-nested' : ctx.package ==='spa' : {} : false
     'postcss-bem':  ctx.package !=== 'spa' && { style: bem } : false
     'postcss-modules': ctx.package === 'spa' && ctx.modules ? {} :  false     
   }
})

webpack.config.js

{ 
   loader: 'postcss-loader', 
   options: { ctx:  { modules: true, package: 'spa' } }
}

Is it really needed? Probably not, but it gives you max control over your config for whatever usecase you might have.

[michael-ciniawsky]

Also, currently in the context a preloader is simply appended to the loaders array with nothing to distinguish it from a normal first loader -- both would be first in the chain (first from the right in the array) -- no enforce property, no nothing. So loaderIndex === loaders.length -1 doesn't guarantee that the current loader is pre.

@Velenir I never understood that feature from the beginning since the loader chain is an array which gets reduced/composed loader3(loader2(loader1())), setting anylint-loader/test-loader related loader as the first in the chain should basically do the same.

use: [ 'style-loader', 'css-loader', 'postcss-loader' (build), 'sass-loader', 'postcss-loader' (lint) ]

My understanding is that we actually might want to go to the opposite direction in the future as it feels like the current css-loader does too much. This would mean pushing the CSS Modules functionality out of it entirely and possibly handling it through postcss-loader.

My understanding is that we actually might want to go to the opposite direction in the future as it feels like the current css-loader does too much. This would mean pushing the CSS Modules functionality out of it entirely and possibly handling it through postcss-loader.

That said, I would love to see a strong design for CSS pipeline as it feels like a sore point at the moment. Simplifying css-loader would just push the problem elsewhere.

@bebraw Actually people even want to use it with postcss-loader when the getting started with all that fuss, the issue here is that postcss-loader lacks the logic to include CSS Modules into the bundle like css-loader does. Then folks switch to the 'css-loaderimplementation of CSS Modules. If someone could enlighten/guide me where/howcss-loaderhandles that I will try to find a solution forpostcss-loader`

// css-loader { modules: true }
import $ from 'style.css'

// postcss-loader { modules: true }
import $ from 'modules.json' 

I have a feeling we might need some kind of concept of context in the design in order to eliminate weirdness like importLoaders index.

How in details does importLoaders work? :)

e.g postcss-import with result.messages.dependency returns all @import paths && postcss-loader adds them to this.addDependencyTo(...messages.dependencies) automatically. Would that be enough to replace it, assuming that loaders like less/stylus/sass-loader take care of adding there @imports to webpack theirselves?

I guess at minimum this might mean a separate option for css-loader where you specify which loaders it should use to parse on @import (loader definition within loader definition).

Simplifying css-loader would just push the problem elsewhere.

Yep, to some point. Sourcemaps, Minifier, CSS Linter, CSS Modules, @import (Loading && Tracking) that's all provided by PostCSS. The problem is the implementation 'chaos', it's just smells like this could be handled in a easier way with the right combo.

                /------CSS*(AST)--------\
bundle.js                                       ------.....
                \------CSS**(STRING)---/

• *PostCSS: Lint, Minify, Modules, @import, plugins ('advanced')
• **: Just include CSS {String} into the bundle ('simple')

So basically postcss-loader 'lacks' advanced webpack support, while on the other hand css-loader 'lacks' advanced postcss support. ¯_(ツ)_/¯

[ai]

@bebraw postcss-loader now offically support plugins parameter in webpack config. https://github.com/postcss/postcss-loader#plugins

Do we need multiple config anymore?

[bebraw]

So basically postcss-loader 'lacks' advanced webpack support, while on the other hand css-loader 'lacks' advanced postcss support. ¯_(ツ)_/¯

That's the core point. Some design decisions are needed. Esp. importLoaders feels like a hack and this particular overlap is troublesome. I'll get more eyes on this.

@bebraw postcss-loader now offically support plugins parameter in webpack config. https://github.com/postcss/postcss-loader#plugins

That looks good to me. 👍

Do we need multiple config anymore?

I'm not sure. Is the above the recommended way now?

[michael-ciniawsky]

@bebraw Could we ask Tobias to guide someone through the css-loader code base?

Do we need multiple config anymo8re?

1. Inline (no postcss.config.js)

const options = { parser: 'sugarss'  map: 'false' }
const plugins = (ctx) => [ require('postcss-import')({ root: ctx.resourcePath }) ]

{
  loader: 'postcss-loader',  options: {...options, plugins: plugins(webpack) } // ctx === webpack
}

2. Common Config (postcss.config.js)

{
  loader: 'postcss-loader',  options: {}
}

3. Common Config (postcss.config.js) Advanced

const config = { file: 'alternative/path/to/postcss.config.js', ctx: {} }

{
  loader: 'postcss-loader',  options: {...config }
}

@ai These 3 should cover 99,9% of usecases and personal dev preferences

[bebraw]

@bebraw Could we ask Tobias to guide someone through the css-loader code base?

Yeah, I'll try to get a little session together. Let's continue on Slack about that.

[ai]

@michael-ciniawsky OK, let’s add config. But I want a PR for it :).

[michael-ciniawsky]

@ai ok, postcss-load-config seems to need revisited for error handling (postcss-cli) beforehand + config.file. The latter I have locally working for a while, mainly bc of #66 (Hotreload postcss.conig.js), but also for postcss-cli now. When resolved I send PR with ctx option + harmonisedctx (ctx.dir/ctx.ext), maybe hotreload if that works (in separate PR).