Cannot read property... about gulp-postcss

[waldemarfm]

Can confirm. Exactly the same errors with same package versions.

[w0rm]

Hi @simbo and @waldemarfm, thanks for reporting this! Recent change was only PostCSS version bump.

It seems that the problem is due to version mistmach between PostCSS and plugins. I checked autoprefixer-core 4.0.2 and found that it depends on PostCSS ~3.0.7

cc @ai

[ai]

Yeap. Should we use peerDependencies in Autoprefixer and other plugins?

[w0rm]

Yeah, seems to be the right way to solve this problem. I will make this change to gulp-postcss as well so users will have more control over which version of PostCSS to use.

[ai]

@MoOx are you agree to add peerDependencies to all plugins? Also I add this recommendation to plugin developer How To (it is in progress right now).

[w0rm]

gulp-postcss now lists postcss in peerDependencies.

[sondr3]

Sorry to bother, but any idea when this will be finished? :)

[MoOx]

peerDep will be deprecated, so not sure it's a good idea.
npm/npm#6565

[MoOx]

The why you should not use dep is overthere npm/npm#5080

[w0rm]

@MoOx any suggestions on how to prevent version mismatch?

[MoOx]

Don't know any magic method. I just too many undesired issues with peerDep too.

Developers should take care of that. When someone upgrade a tool with some plugins, this person should ensure all plugins have versions that work with the new version of the tool. IMO, it's that simple.

Each plugins might specify minimal version they require in their README.

[MoOx]

Note that all the plugins I published for example have tests with a specific postcss version (cf devDep). Developers can also take a look to that. Version in README seems a good idea tho.

[ai]

Maybe we can set some special flag to plugin with PostCSS AST version they required? I do not really like this idea, only as brainstorm.

[ai]

Like:

module.export = {
    postcss: function () {},
    ast: '4.0.0'
}

And PostCSS will throw error if plugins expect different AST versions.

[MoOx]

Maybe more

module.export = {
    postcss: function () {},
    postcssVersion: require("./package.json").devDependencies.postcss
}

?

Note sure we should handle this in the core tho.
We all get this kind of issue with all tool/plugins things, this is not likely easy to solve.

[w0rm]

If each plugin exposed its postcss version from package.json, then postcss itself could check it with smth like https://github.com/npm/node-semver and throw an error

[ai]

Main problems:

1. Does API check is a part of PostCSS?
2. What we will suggest to user? Downgrade plugin version?
3. I think short plugin syntax (just a function) is important on debug. Should we allow it and miss API check it this case?

[w0rm]

This suggestion seems to be the way how this should be solved npm/npm#5080 (comment)

[yisibl]

It is certainly a headache problem.

[MoOx]

I like the way isaac explains. So this can be handled in plugin like this:

var plugin = function () {}

plugin.supportedVersion = require("./package.json").dependencies.postcss || require("./package.json").devDependencies.postcss

module.export = plugin

It would be could to directly add a supportedVersion property to the plugin itself.
This way, postcss can check for this without having to rely on a object that contains function+supported version.

What do you think guys?

Btw, this should only show a warning because for example a plugin done for v3 can totally work for v4 (the otherwise is not likely to work all the time).

[ai]

I found the best solution. We dont necessarily have to use one AST version in every plugin. If plugin uses old AST we can stringify current one and then reparse it with old PostCSS for this plugin.

Every plugin should have own PostCSS version in dependencies and will use special mathod to wrap plugin function:

var postcss = require('postcss');

module.exports = postcss.plugin(function (css) {
    // css will be in plugin’s PostCSS version
});

postcss.plugin will be like:

postcss.plugin = function (plugin) {
    return function (ast) {
        // here will be smarter semver check
        if ( ast.postcss.version == postcss.version ) {
            return plugin(ast);
        } else {
            var old    = postcss.parse( ast.toResult() );
            var result = plugin(old);
            return ast.postcss.parse( result.toResult() );
        }
    };
});

[MoOx]

Overkill !
We should not take care of this. It's up to the developer to know which version of the tool he use, & so which version of plugin to use too.

Your solution might create slow result if several postcss plugins use severals versions of postcss.
Sound like over-engineering to me.

We don't have to handle this kind of issue...

[ai]

@MoOx but slow plugin is better, that broken plugin :)

[MoOx]

Also, you will have to face a new problem cause a new version might parse something a previous version fails to. You don't want user to want an report issue about that.

Plugin is not broken, just no compatible (yet?).

[kristoferjoseph]

Sooo,
What steps does one need to take to get the documented example in the README to work without error?
Thanks :)

[ai]

Autoprefixer 5.0 was released with PostCSS 4.0 support. Please update.

[w0rm]

@MoOx @ai should I revert commit that made postcss into peerDepency or is it fine for gulp plugin?

[w0rm]

@kristoferjoseph PR for the README is very welcome!

[ai]

@w0rm I am not so familiar with npm :(. @MoOx knows better.

[MoOx]

Note: I don't use gulp anymore so I don't care =)

Since npm plan to deprecate this feature, I think you should not use this.
And it brings the exact same kind of issue as normal dep: webpack/webpack#570 (comment)

[TrySound]

If somebody needs old plugin, let use old versions of other plugins and postcss. Without peerDep

[w0rm]

@MoOx so webpack loaders are the new hype thing =)

@TrySound to use with previous version of postcss simply pick corresponding version of gulp-postcss from the change log.

[TrySound]

Yes, I am about it.

[MoOx]

(@Worm my build process is more based on npm itself (npm scripts) than on webpack. Check it out https://github.com/MoOx/frontend-hot-starterkit)

Maybe we should close this issue for now (and encourage people to read CHANGELOG & README & package.json).

[MoOx]

Maybe an issue should be created to postcss directly.

[ai]

I created this issue postcss/postcss#163

[MoOx]

Perfect.

[w0rm]

Put PostCSS back into simple dependency and republished on npm (commit)

[ai]

Next PostCSS 4.1 will print warning if plugin throwed a error and was based on different PostCSS version: postcss/postcss@3d48436

[sidoruk-sv]

The same issues can occur when you make a mistake in an array of processors and undefined item appear in a row:
[processor1,, processor2]