Postcss: Q: Should plugins have PostCSS in dependencies?

Created on 21 Nov 2015  路  9Comments  路  Source: postcss/postcss

I got some issues related to this question (see this). In short, I think plugins should have PostCSS in peerDependencies and devDependencies if it's needed. Didn't find information about it in docs. Quick check shows me that every plugin does it in its own way :)

What is your poin?..

Most helpful comment

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:

  1. Many major releases do not change plugin API. This is why default 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.
  2. Also in real word plugins are quite more compilcated, than just a function. Plugin builder is useful thing.
  3. Many plugins anyway use 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.

All 9 comments

@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

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:

  1. Many major releases do not change plugin API. This is why default 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.
  2. Also in real word plugins are quite more compilcated, than just a function. Plugin builder is useful thing.
  3. Many plugins anyway use 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AdeSupriyadi picture AdeSupriyadi  路  3Comments

ZeeCoder picture ZeeCoder  路  7Comments

aslushnikov picture aslushnikov  路  10Comments

jbg picture jbg  路  14Comments

buhlahkay picture buhlahkay  路  3Comments