Allow control over loader exec.

[10xjs]

An exec flag can be provided to the loader query or webpack config. This instructs the loader to load the source using exec. This enhances the previous behavior which was to check that the loader query parser was strictly equal to postcss-js.

This fixes an issue where the postcss-js parser cannot be specified through the webpack postcss config option.

This also enables parsers other than postcss-js to receive executed module results.

[ai]

Hm. Adding a new option looks like a hack. Other developers with same issue could miss this option.

Could you describe this issue, that you want to fix here? Maybe we will find some better way?

[10xjs]

This is basically a fix for #86
EDIT: This is not a fix for #86

[10xjs]

It's useful to be able to conditionally load the required module with exec. This opens the door for parsers other than postcss-js and allows support for specifying the postcss-js parser in ways other than ?parser=postcss-js in the loader query.

We will be able to do this:

module.exports = {
    module: {
        loaders: [
            {
                test:   /\.style.js$/,
                loader: "style-loader!css-loader!postcss-loader"
            }
        ]
    },
    postcss: function () {
        return {
            parser: require('postcss-js'),
            exec: true,
        };
    }
}

Or this:

module.exports = {
    module: {
        loaders: [
            {
                test:   /\.style.xyz$/,
                loader: "style-loader!css-loader!postcss-loader?parser=custom-parser&exec"
            }
        ]
    },
}

[10xjs]

@ai Having the parser itself define the exec behaviour is also an option.

In https://github.com/postcss/postcss-js/blob/master/index.js, for example:

  var postcssJs = {
      objectify: require('./objectifier'),
      parse:     require('./parser'),
      async:     require('./async'),
      sync:      require('./sync'),
+     __webpackExec: true,
  };
  module.exports = postcssJs;

And then in the loader:

-   if ( params.parser === 'postcss-js' || exec ) {
+   if ( opts.parser.__webpackExec ) {
        source = this.exec(source, this.resource);
    }

[ai]

Yeap, we could change API. postcss-js is not so widely used, so we could change it.

[ai]

I don’t like the __webpackExec: true property in parser. It looks like hack ;).

Maybe we should add parserExec parameter? But it will be a string parameter ?parserExec=postcss-js.

I would be happy to avoid changing array to object in postcss section of webpack config (because it will affect to many users). Any suggestions?

[10xjs]

/cc @izaakschroeder

[10xjs]

@ai What do you mean about "array to object". The changes I have staged are 100% compatible with the existing interface. This should have absolutely no impact on current users.

[ai]

@nealgranger

postcss: function () {
        return {
            parser: require('postcss-js'),
            exec: true,
        };
    }

Right now postcss section in webpack returns only plugins list.

[10xjs]

there's already a case for this: https://github.com/postcss/postcss-loader/blob/master/index.js#L59. The webpack config can be an array or an object with a plugins array.

[ai]

Ouh, I forget about it :(. Sure, we could add parser option to postcss section.

But what if developer need postcss-js to some files and CSS parser to others?

[10xjs]

@ai The loader query syntax is still supported of course.

I'm currently doing something similar to this:

loaders: [
  {
    test:   /\.css$/,
    loader: "style-loader!css-loader!postcss-loader"
  },
  {
    test:   /\.css\.js$/,
    loader: "style-loader!css-loader!postcss-loader?parser=custom-parser&exec"
  }
]

[ai]

I am suggesting to remove postcss-loader?parser=postcss-js for postcss-js.

Let’s introduce one way to load exec based parsers. Because I don’t like exec option idea — other developers could miss this option.

[10xjs]

@ai The exec option is not necessary if you are using ?parser=postcss-js. This is a totally non-breaking enhancement.

[10xjs]

@ai Were you thinking of a separate parameter like ?execParser=custom-parser?

[ai]

I know. But what if other developers got #86? How did he find this exec option?

This is why I suggest to change how we load postcss-js. So having #86 will be impossible.

[10xjs]

I understand #86 better now, exec is not supported when using happypack.

The solution would be to allow using plain old require instead.

[10xjs]

We would need a way to specify whether to use loader.exec, require or nothing at all.

[ai]

Sure, let’s use something like this instead:

    postcss: function () {
        return {
            parser: require('postcss-js'),
            plugins: [require('autoprefixer')]
        };
    }

[ai]

Other question: how it will be changed in webpack 2 ;)

[10xjs]

..and have ?parser=postcss-js automatically trigger exec for compatibility.

[10xjs]

how does

    postcss: function () {
        return {
            parser: require('postcss-js'),
            plugins: [require('autoprefixer')]
        };
    }

trigger using exec?

[ai]

Hm, mayb I miss the point. Could you repeat what is the problem?

[10xjs]

How does the loader know to call exec in the example postcss config above?

[ai]

@nealgranger I mean what is the main problem? #86 was that exec doesn’t work in some environments.

[10xjs]

I was wrong to say that this is a fix for #86

[10xjs]

To solve #86, we would need to do something like:

if ( params.parser === 'postcss-js') {
  source = require(source);
}

which would prevent any code in the source file from being processed with webpack, but at least it would work.

[ai]

OK. So why you need this PR? To run postcss-js behavior to some custom parsers?

[10xjs]

yup

[10xjs]

I'm currently doing:

export const parse = (source) => postcssJs.parse(transformSource(source)));

as a "custom" parser

[10xjs]

@ai It's getting used here https://github.com/webpack-config/webpack-config-postcss/compare/postcss-js?expand=1.

[ai]

Sure, let’s me finish with PostCSS 5.2 and I will return to this issue.

[10xjs]

I hadn't considered parserExec=my-parse until our conversation. I do prefer?exec though. It avoids the ambiguity of ?parserExec=my-parse?parser=other-parser.

[10xjs]

@ai Thanks for looking at this!! 😄

[ai]

Sure, I agree that parserExec was a bad idea, because exec is about style file, to a parser.

[ai]

Please check docs 54a644e

[ai]

Released in 0.13.