Integrate with postcss by default

[yordis]

Can we integrate this plugin with some css processor like postcss (autoprefixer). At this point dealing just with prefixes, no only this, is kind a pain so will be very valuable have this by default.

[jgrenat]

👍
I was searching how to implement autoprefixer and cssnext with this plugin. It would be nice allowing to hook before the minification process to customize it.

[guybedford]

Yes this is very much the plan. @geelen has been working on this in the next version of the module at geelen/jspm-loader-css#3 (comment).

[yordis]

@guybedford I was reading a little bit about #30 and I think this should be just CSS without any enhancement outside of something like autoprefixer.

The reason is because everyone try to create something on top of CSS and sometimes even dictator about it. I propose this issue because right now in 2015 dealing with prefixes, in my case, is not something we should do when we actually have very good libraries for that.

But, I really don't like the idea of make another layer of complexity on top of CSS or even add the modular css idea to this plugin. Just keep it simple as is, just CSS.

Ideas like integrate with Javascript the way I can actually use those classes styles come from React and these ideas are great but at the same time I don't feel they have to be inside something that important like this plugin

[jgrenat]

@yordis To my opinion, we can use both an autoprefixer and a transpiler for the future CSS syntax (like custom properties) (and not support custom syntax like sass and less do).

[yordis]

@jgrenat I like evolution but at the same I don't like to create something outside of CSS, again, and end in crazyness dependencies with these tools. That's why I said that, I like the future but people need something for today and realistic most of the time we just need: variables and nested selectors and some autoprefixes magic

[yordis]

@guybedford I did some something here f929844 As you can see in line 24 we can do whatever we want with that text so the next step can be add postcss with some configuration.

[guybedford]

Right, https://github.com/geelen/jspm-loader-css/blob/master/index.js does the same thing. Help testing that project would be very welcome as the plan is to merge that work.

[guybedford]

I've corrected the link (https://github.com/geelen/jspm-loader-css/blob/master/index.js)

[yordis]

@guybedford so there is anything to do just wait for @geelen 👍

[geelen]

Morning! Have been on client work the last few days so haven't been watching the issue tracker.

So, jspm-loader-css is designed to be a flexbile PostCSS loader. By default it has:

• CSS Modules opt-in (so nothing runs unless you declare a :local block)
• Autoprefixer with default settings

So if you pass this any random CSS file it'll prefix it and nothing else. Which I think should be the default behaviour.

From chatting to @guybedford, I'm sort of unsure about making the plugin configurable, because defining your own plugin is pretty easy: https://github.com/geelen/jspm-loader-css-modules/blob/master/index.js (this is the full CSSModules plugin chain which is opt-out)

For my projects, I've made a css.js next to my index.html defining the plugin chain I want to use. For example, my blog: https://github.com/geelen/glenmaddern.com/blob/master/src/css.js

I quite like this approach, since you really don't have to do much at all to make custom loaders in JSPM (:sparkling_heart: for that) and you can write arbitrary PostCSS transforms if you feel like it. It also means that publishing a particular collection of PostCSS transforms is easy (like I do with the full CSS Modules one). So we could easily spin one up for css-next, for example.

The alternative is coming up with a config syntax and managing it there. Happy for some ideas here.

[yordis]

@geelen so I think the next move is configure the plugins, do something like css: { plugins: ['autoprefixer', ...] } or an object because sometimes you can configure the plugin css: { plugins: [ { 'post-nested': { bubble: ['phone'] } }, ...] }

[yordis]

@geelen btw if we integrate cssnext by default we got autoprefixer inside so I would like to see at least nested and cssnext by default in jspm-loader-css

What do you think?

[geelen]

I don't think anything more should be included by default, my point is we (you?) could maintain a jspm-loader-cssnext that is as simple as jspm-loader-css-modules (since all it has to do is define an index.js that creates the loader with all the plugins and exports it). Does that make sense?

[yordis]

@geelen I understand if we want to add new plugins we just need to add a layer on top like that index.js that you shown there but can we do something like:

Instead of create that file because we want to use new plugins. `jspm-loader-css`` allow us to specify some plugin configuration. That way is easier for developer to use new plugins, they just need to installed and configure it.

[geelen]

This is actually a problem I have with PostCSS — you need to install 4 or 5 different plugins to get useful functionality. That's why cssnext is such a good idea: it's a thematically linked set of plugins. In my mind, you want to argue for the relevance of a particular set of plugins, and give it a name so that people can identify and evaluate it. For example, you could publish something like jspm-loader-sass-lite which has stuff like nesting, simple-vars, mixins, extends, color functions & autoprefixer.

As for configurability, jspm-loader-css is configurable, just not through System.config. All you need to do is create a css.js file in your project and do:

import { CSSLoader, Plugins } from 'jspm-loader-css'
import vars from 'postcss-simple-vars'
import nested from 'postcss-nested'

export default new CSSLoader( [ nested, vars, Plugins.autoprefixer() ], __moduleName )

Whether we add some configurability to System.config is up to @guybedford, but I'm thinking it might be better to teach people about building their own simple plugins instead?

[yordis]

@geelen I understand. Thanks a lot