PostCSS package and Meteor Build Plugin questions

packages
1

Hi, I have built a package which is a separated PostCSS build plugin. I need some help and feedback…

I want to add PostCSS package and then I want to configure PostCSS plugins without changes in the main build plugin in meteor package. So my approach is to create local package with Npm.depends and json config file… and this is done already.

Please could you take a look at the package here: https://atmospherejs.com/juliancwirko/postcss there are some questions and description.

My main questions:

  1. How to hook PostCSS to .css extension in Meteor build plugin? It will be cool if we could use for example Stylus as an separated build plugin and then PostCSS on generated css. For now I use .pcss extension :confused:
  2. How to load custom PostCSS plugins without changing the main PostCSS build plugin file? Is there a way to customize our Meteor build plugins by adding new npm packages from outside the package without nasty hacks?
  3. Can we do this simpler than in my package?

My thoughts:

  1. I think that the Build Plugins API in Meteor should be better documented :disappointed_relieved:
  2. I realy want to use .css extension :disappointed_relieved:

Thanks.

1 Like
2

There’s some conversation about this here:

The conclusion is, we should build this into the minifier. This is very high priority since a lot of people are worried that it is hard to use autoprefixer.

Here are some relevant issues on GitHub:

Unfortunately I won’t have time to work on this stuff this week. Let me try to answer your questions:

Answers to questions

  1. It shouldn’t be hooked up as a CSS compiler, since then you can’t use it with LESS, SCSS, etc. The logical place right now is inside the minifier.
  2. Loading custom plugins should currently be done the same way cosmos:browserify does it, which is a huge hack but seems to work well for Browserify transforms: GitHub - elidoran/cosmos-browserify: Browserify npm modules for client side in Meteor packages
  3. Sorry, I don’t have time to look at the package at the moment.

Answers to thoughts

  1. Yes, the documentation is not good in this area.
  2. See (1) above.
3

Many thanks for the answers and links. I’ll study it. :+1:

4

@sashko So if I understand it correctly I need to prepare a copy of standard minifiers and use the .css one? I think it should be divided into two packages - JS and CSS standard minifiers, don’t you think? Because I don’t need a copy of js minifier in my custom package and now I think I don’t have a choice because I need to remove ‘standard-minifiers’ package from the project if I want my own css minifier. Am I right?

5

There is an update. All is based on minifiers now: https://atmospherejs.com/juliancwirko/postcss feedback needed :wink:

1 Like
6

Gonna check it out now!

7

You’re right.

  1. I’d love to accept a PR splitting standard-minifiers into two packages, one for CSS and one for JS. Perhaps you can still add both as standard-minifiers, but there could be sub-packages like standard-minifier-js and standard-minifier-css
  2. Eventually, I’d love for postcss to be built into the standard CSS minifier, once we can validate the approach with your package.
2 Likes
8

I currently have this, which uses postcss: https://atmospherejs.com/seba/minifiers-autoprefixer

I was looking for a way to add more postcss plugins, going to check out the browserify approach

1 Like
9

Yeah, it also bothered me that these are together. I’m going to create a PR for this.

1 Like
10

I made it work but I will try to rewrite it a little bit to use meteorhacks npm-container. I’ll try to do it in couple of hours.

11

Also related: https://github.com/meteor/meteor/issues/5512

12

For now I have something like this: https://github.com/juliancwirko/meteor-postcss works quite well (so far ;))

1 Like
13
2 Likes
14

Hey, one problem with using the package instead standard-minifiers is that some of community packages has it in dependencies (I wonder why?). This is a blocker for many people when you want to replace it with something different like for example juliancwirko:postcss package. Even when you remove standard-minifiers meteor will install it again.

I think there should be info somewhere to not use such packages in other custom packages or standard-minifiers should have special logic which will check if there is other minifier active. I don’t know… :confused:

Good example Orion : https://github.com/orionjs/orion/blob/master/packages/base/package.js#L14

This is bad because some packages are doing the same. What’s your opinion about that @sashko ?

1 Like
15

My two articles about PostCSS usage in Meteor:

1 Like
16

Can I still use a preprocessor (specifically Stylus [mquandalle’s]) ?

17

Yes! This postcss package runs after the stylus package would.

1 Like
18

Cool! So I don’t need to bother with something like https://github.com/seaneking/poststylus ?

19

Nope! That’s the goal of this package - letting you use your favorite pre-processor independent of postCSS.

2 Likes
20

Yeah, you can still use your fav preprocessor. PostStylus is just a Stylus plugin which uses PostCSS.

This is the article that I wrote some time ago:

It helps to understand what PostCSS really is.

1 Like