@OEvgeny Just look at existing plugins. Plugins are defined with postcss.plugin function. So, postcss should be in regular deps to have ability to use this function. Also peerDependencies are deprecated for a long time. So, never use it.
Ok. thanks. Didn't know about peerDependencies deprecation.
I check plugins and some of them didn't have PostCSS in deps (eg postcss-host).
So, I think will be good to add this info into plugin guidelines..
@OEvgeny That's the same mistake. Better check plugins which in postcss org.
@OEvgeny The rule: everything u require in module code (not test and build code) you should place in regular dependencies
@TrySound I know. But it also means that with npm@<3 it will install PostCSS for each plugin in plugins directory. It's not needed for regular user, because postcss will be installed anyway to call .use() to plugin.
Of course with npm@^3 it works better. In this case it just slows dependecies resolving.
@OEvgeny You still can install postcss as dep, but not use it. I did such thing before move to npm3
https://github.com/TrySound/case/blob/master/package.json
@TrySound You're wrong. peerDependencies wasn't deprecated:
https://docs.npmjs.com/files/package.json#peerdependencies
https://github.com/npm/npm/issues/6565#issuecomment-74971689
Let鈥檚 I clear this thing.
Every PostCSS plugin should be created by postcss.plugin(). This method is in postcss, so every plugin must have postcss in dependencies.
The reasons:
peerDependencies mechanism is not ideal for us. We use different: every plugin contains plugin.postcssVersion with its PostCSS version. If plugin throw a error and its version is different, we show a message, thet problem is in PostCSScore conflict. Also using plugin.postcssVersion we can even change AST API for older plugins.postcss for AST transformations methods like postcss.rule().Of course, every reason can be solved in many different ways. But in general we found that this solution is better for PostCSS purpose.
Maybe in PostCSS 6 we will have some tiny postcss-plugin creator. But only if PostCSS was popular in CSS-in-JS world.
@ai Thanks for clarification.
Most helpful comment
Let鈥檚 I clear this thing.
Every PostCSS plugin should be created by
postcss.plugin(). This method is inpostcss, so every plugin must havepostcssindependencies.The reasons:
peerDependenciesmechanism is not ideal for us. We use different: every plugin containsplugin.postcssVersionwith its PostCSS version. If plugin throw a error and its version is different, we show a message, thet problem is in PostCSScore conflict. Also usingplugin.postcssVersionwe can even change AST API for older plugins.postcssfor AST transformations methods likepostcss.rule().Of course, every reason can be solved in many different ways. But in general we found that this solution is better for PostCSS purpose.
Maybe in PostCSS 6 we will have some tiny
postcss-plugincreator. But only if PostCSS was popular in CSS-in-JS world.