Project "Stabilize minimizer" about management

[alexander-akait]

@michael-ciniawsky if you have ideas - welcome to slack, this repo not for discussion about implementation minimizer features in webpack.

[michael-ciniawsky]

This effort ideally takes the interface introduced with webpack >= v4.0.0 into account (optimization.minimize) and removes the need for optimization.mimimizer as an alternative way to add multiple minimizer plugins (which is the same as adding multiple plugins via config.plugins atm 🤷‍♂️). A webpack wrapper (minimze|optimization)-webpack-plugin based on the uglifyjs-webpack-plugin code should be sufficient and easier to use and maintain

webpack.config.js

const config = {
   optimization: {
      // Defaults for '.js', '.css', '.html', maybe based on mode (recommended)
      minimize: true || false // {Boolean}
      // 'Advanced' (Interface)
      minimize: {
        '.js': '{Boolean}' || { /* Babel Minify Options */ } || '{Function}' // (e.g terser)
        '.css': '{Boolean}' || { /* CSSNano Options */ } || '{Function}' // (e.g csso)
        '.html': '{Boolean}' || { /* HTMLNano Options */ } || '{Function}' // (e.g html-minifier)
      },
      // Custom Minimizer {Function}
      minimize : {
        // Override/Register a custom minimizer { 'extname': workerFn }
        '.ext': (asset, options, cb) => {}
      }
   }
}

[alexander-akait]

@michael-ciniawsky i don't think it is good idea use this:

      minimize: {
        '.js': '{Boolean}' || { /* Babel Minify Options */ } || '{Function}' // (e.g terser)
        '.css': '{Boolean}' || { /* CSSNano Options */ } || '{Function}' // (e.g csso)
        '.html': '{Boolean}' || { /* HTMLNano Options */ } || '{Function}' // (e.g html-minifier)
      },
      // Custom Minimizer {Function}
      minimize : {
        // Override/Register a custom minimizer { 'extname': workerFn }
        '.ext': (asset, options, cb) => {}
      }

It is require webpack have cssnano/htmlnano/etc in deps (because each plugin have minificator in deps). Also webpack doesn't support css/html by default. It's better to let people choose which plugin they want.

[michael-ciniawsky]

Sure, using separate plugins for each asset type is an equal alternative, but then the optimization.* options are more confusing then just using config.plugins directly instead imho (in terms of API design, e.g see the mini-css-extract-plugin README). An abstraction/wrapper could also ship without .css/.html support by default and one has to register minifiers for these

The worker of a potential wrapper plugin could still support different assets types by extension, instead of having to redundantly code this for each and every minifier plugin

worker.js

function worker (asset, options, cb) {
   const type = path.extname(asset.url)

   switch (type) {
     ...js

     case '.css': 
       options[type](asset, options, cb)
          
       break

    ...
  }
}

But on the other hand maybe it's better solved with some kind of plugin-utils providing this functionality (workers, cache) for plugins in general instead idk...

[michael-ciniawsky]

Yep Yep sry :)