postcss-loader 'config' validation error

[gonewild22]

I've updated to postcss 8.1.0 and postcss-loader 4.0.3 and get this validation error now:

Invalid options object. PostCSS Loader has been initialized using an options object that does not match the API schema.

• options has an unknown property 'config'. These properties are valid:
  object { postcssOptions?, execute?, sourceMap? }

After some research I've found out that postcss-loader has changed their options hash. They lie now under "postcssOption".
Therefore this:

   loader: 'postcss-loader',
      options: {
        config: { path: resolve() },
        sourceMap: true
      }

should be changed to:

  loader: 'postcss-loader',
      options: {
        postcssOptions: {
        config:  resolve() ,
        },
        sourceMap: true,
      },

(in package/utils/get_style_rule.js.)
Is it legit to do this manually to resolve this issue temporary? (in my node_modules folder)

[ChadMoran]

As a hotfix I added the following to my environment.js

environment.loaders.keys().forEach(loaderName => {
  let loader = environment.loaders.get(loaderName);
  loader.use.forEach(loaderConfig => {
    if (loaderConfig.options && loaderConfig.options.config) {
      loaderConfig.options.postcssOptions = loaderConfig.options.config;
      delete loaderConfig.options.config;
    }
  });
});

[gonewild22]

How great! Works like a charm, thx a lot! :)

[luca-aurelia]

Thanks @ChadMoran! I tweaked your solution to be a little more explicit, and to specifically check if the loader in question is postcss-loader before changing its config:

function hotfixPostcssLoaderConfig (subloader) {
  const subloaderName = subloader.loader
  if (subloaderName === 'postcss-loader') {
    subloader.options.postcssOptions = subloader.options.config;
    delete subloader.options.config;
  }
}

environment.loaders.keys().forEach(loaderName => {
  const loader = environment.loaders.get(loaderName);
  loader.use.forEach(hotfixPostcssLoaderConfig);
});

[natematykiewicz]

function hotfixPostcssLoaderConfig (subloader) {
  const subloaderName = subloader.loader
  if (subloaderName === 'postcss-loader') {
    if (subloader.options.postcssOptions) {
      console.log(
        '\x1b[31m%s\x1b[0m',
        'Remove postcssOptions workaround in config/webpack/environment.js'
      )
    } else {
      subloader.options.postcssOptions = subloader.options.config;
      delete subloader.options.config;
    }
  }
}

environment.loaders.keys().forEach(loaderName => {
  const loader = environment.loaders.get(loaderName);
  loader.use.forEach(hotfixPostcssLoaderConfig);
});

Working off @noise-machines (and therefore @ChadMoran), I added a log line that yells at me when this is no longer necessary. It prints the text in red.

Also, I'm pretty sure when this isn't necessary anymore, subloader.options.config will be undefined, so subloader.options.postcssOptions = subloader.options.config; will overwrite postcssOptions to be undefined, and I'm not sure what would happen then. So, that's a reason to only do this if we don't have postcssOptions.

[brian-kephart]

I'm seeing this issue as well.

[psantos10]

As a hotfix I added the following to my environment.js

environment.loaders.keys().forEach(loaderName => {
  let loader = environment.loaders.get(loaderName);
  loader.use.forEach(loaderConfig => {
    if (loaderConfig.options && loaderConfig.options.config) {
      loaderConfig.options.postcssOptions = loaderConfig.options.config;
      delete loaderConfig.options.config;
    }
  });
});

I tried both workarounds shared here, but its giving me the following error:

ERROR in ./app/assets/stylesheets/application.scss (./node_modules/css-loader/dist/cjs.js??ref--6-1!./node_modules/postcss-loader/dist/cjs.js??ref--6-2!./node_modules/sass-loader/dist/cjs.js??ref--6-3!./app/assets/stylesheets/application.scss)
Module build failed (from ./node_modules/postcss-loader/dist/cjs.js):
TypeError: this.getOptions is not a function
    at Object.loader (/Users/psantos/Projects/Learning/modern-css-with-tailwind/rails-tailwind-demo/node_modules/postcss-loader/dist/index.js:38:24)

My pachage.json has the following pagackages:

"postcss": "^8.2.4",
"postcss-loader": "^5.0.0",

Any idea?

[psantos10]

...
My pachage.json has the following pagackages:

"postcss": "^8.2.4",
"postcss-loader": "^5.0.0",

Any idea?

Never mind.

I had to change the version number to 4.2.0 : "postcss-loader": "4.2.0",

Version 5.0.0 was just released with a breaking change.

[mcmaddox]

God bless you for this the hotfix, @ChadMoran. 2 years later and this is (still) the way...

[natematykiewicz]

@mcmaddox Webpacker is retired. You should consider switching to jsbundling-rails and maintaining your own Webpack config, or webpacker's actively maintained fork shakapacker. There's more information in Webpacker's readme.

[mcmaddox]

@natematykiewicz In your opinion, which solution is preferred for an app that hasn't migrated to Rails 7 yet (still on 6.1)?

[natematykiewicz]

It all depends on how much you like Webpack vs the other bundlers (rollup, esbuild), and if you prefer webpack do you want to maintain your own config.

jsbundling-rails is unopiniated. It's simply a gem that runs your bundler of choice and wires its output into the asset pipeline for serving.

Shakapacker continues off where webpacker left off.

Some people really like webpack and want an automatic config (Shakapacker). Others like webpack but want to configure it themselves, or prefer something faster like esbuild, so they use jsbundling-rails.

This discussion gives you a ton of information about the topic. https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851

I personally have switched employers and only use Hotwire these days.

[mcmaddox]

@natematykiewicz Thanks for the link!