cssnext option

[guybedford]

I just posted systemjs/systemjs#579, and was thinking a similar property for CSS might work well.

A meta property which could enable CSS next transpilations per-CSS module.

Deeper option configurations could potentially be provided via System.postCSS or something like that (the name of the transpiler system being used).

The idea is that it would be nice to have a single CSS plugin (the custom factories work well, but it still seems an unnecessary layer for "css next" principles?), which can be configured to be in two modes - basic CSS loading, and CSS next.

Further CSS transforms beyond the above is certainly via a custom factory etc, but for the above it would be really nice to have a streamlined workflow.

Just throwing this stuff out there. Perhaps we need to try and get this work sponsored :)

[yordis]

@guybedford I am going to work in some idea like css4-plugin that actually use this one but with default packages. Rather than I would like to see it in this package but it's outside of my scope right now

[yordis]

@guybedford can you help me out to define the default css plugins please. I am going to start working on this, should be easier

[geelen]

Yeah, ok. After living with the plugin-factory thing for a while I don't really like it. I think we need a configuration option. So that something like cssnext, or precss, or CSS Modules, or whatever, can be simply opted into. So assuming we've started with this:

jspm install css
jspm install npm:cssnext

The question is, how do we tell the loader to use cssnext? We could add something like:

System.config({
  "css": {
    "plugins": ["cssnext"]
  }
});

Could we add something to the cli that means we could run jspm config css-plugins=cssnext?

Questions are, how do we handle multiple plugins on the CLI? How do we handle autoprefixer arguments (like which browsers to support)? These are the stuff that the browserify and webpack teams already deal with, but I don't want to copy-paste their ideas if JSPM gives us a better way.

[yordis]

@geelen thaaaaaaaannkk 👍

About the multi plugins config we can do something like or just the regular array. I think the good thing about jspm is about easier to setup.

We can "copy" but redefining if there is a better way to do it and very important if we can get it done without do anything. And we should have defaults config for the plugins, or at least the main ones, so you don't need to write anything if you don't need it. There is a common config most of the time.

System.config({
  "css": {
    "plugins": {
      "cssnext": {
        "any": "config here"
      },
      "I am the ugly one": true || {  }
     }
  }
});

[guybedford]

@geelen I do think both functionalities should come from the same core CSS plugin. Perhaps a bridging plugin that links the two together. The reason being that CSS is a dependency in a lot of places, and this is a place where we do need a "one for all" solution.

Given the above, the solution I was thinking of was something along the lines of:

System.config({
  meta: {
    "*.css": {
      loader: "css"
    },
    "app/*.css": {
      cssnext: true
    },
    "components/*.css": {
      csm: true,
      cssnext: true
    }
  }
});

Ideally there would then be one css next that does everything.

Do you see any issues with an approach like the above?

[geelen]

The biggest issue is customising pipelines. If I wanted to add nesting to cssnext, say, how could I do that? Order of plugins is also important. And autoprefixer (and maybe other plugins) actually take arguments. The browserify plugin for CSS Modules had to do this to specify arguments on the command-line https://github.com/css-modules/css-modulesify#postcss-plugins

System.config({
  meta: {
    "vendor/*.css": {
      loader: "raw-css"
    }
    "*.css": {
      loader: "css"
    }
  },
  loaders: {
    css: {
       loader: "jspm-loader-css",
       plugins: ["postcss-nested", "cssnext"]
    },
    "raw-css": {
      loader: "jspm-loader-css",
      plugins: []
    }
})

Thoughts?

[guybedford]

Yes this needs to be carefully considered. I really like the plugin approach you've shown above, but for complete isolation it should be applied through meta:

System.config({
  meta: {
    "vendor/*.css": {
      loader: "css"
    }
    "*.css": {
      loader: "css",
      plugins: ["postcss-nested", "cssnext"]
    }
  }
})

The plugins get loaded in the context of the module - eg import "path/to/file.css" will use the plugin System.import('postcss-nested', 'normalized/path/to/file.css'). This way plugins are fully-isolated into the parent package.

This complete isolation would allow packages to publish modular CSS transformations, with the final build being managed by the consumer, without the need for pre-compilation.

In terms of the value, I am still on the fence on the pre-compilation side of things (ie do we publish modular raw CSS and ES6, or do we publish pre-compiled into raw CSS and System.register ES5). Of course both are always allowed, it's just about how much to push the ES & CSS next publishing and if that's important or should be avoided entirely. Would be interested to hear thoughts.

[guybedford]

The major benefit I see to allowing ES & CSS next publishing would be the code analysis benefits, which may be a tipping factor here. Hence the isolated configuration suggestion.

[yordis]

@geelen any updates on this?

[geelen]

Nothing as yet, sorry. I'm gearing up for a CSS Modules talk at React Rally in a bit over a week which, combined with working full-time now, has eaten up all my time. I'm speaking on day 1 there, though, so maybe day 2 I can spend hacking on JSPM stuff :)

[geelen]

So, day 2 of the conference I got sick as shit so I'm just now poking my head up. I have a 15 hour flight tonight with wifi so maybe I'll make some progress there!

[patrickmichalina]

Anywork done on this? What would be the current approach to getting cssnext into the jspm pipeline? If there isn't one, any tips on using how I can use the newer css-variable syntax to work on older browser in a JSPM project?

[peteruithoven]

Maybe the following fork is interesting: https://github.com/MeoMix/jspm-loader-css
It supports PostCSS plugins, maybe you can use that cssnext that way?
I still have to try this form, but MeoMix has been working on this for a while.

[patrickmichalina]

@peteruithoven thanks. I have been experimenting but I don't think that approach works well with Angular 2 which already encapsulates components with their own CSS. What I really need is to be able to share variables across CSS for sub-components. Still researching the nominal approach