You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 9, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 9, 2020. It is now read-only.
We can then enable an architecture based on CSS "processors", and offer the ability to configure custom processing steps for builds like auto-prefixing.
Just to clarify, cleanCSS is currently only used when doing a jspm bundle? I'd quite like to have at least autoprefixer running in dev mode, so was just about to look into this issue. Do you think it'd be worth starting a plugin-postcss project instead?
Would the user have any control over which postcss plugins were being used?
Yes exactly - currently we only do operations at bundle time.
I do like the idea of moving to a compilation-based CSS workflow, and will happily get this plugin on board with that assuming all the dev hurdles can be conquered.
Global config options on the System object itself could enable CSS operations like auto-prefixing. Note that I'm not a fan of allowing any arbitrary operations though, as we can't have per-package configuration, so need to base it on a sensible baseline.
In terms of creating more advanced compilation workflows into CSS (LESS / SASS / etc), this can be handled by composing other plugins with the CSS plugin (basically extending the CSS plugin).
The last issue is how to get this approach to work in IE8. For that, I guess we can forgo the debugging <link> blob injection and just fall back to a more standard <style> injection.
I would love to get started on this as I really need this feature. I have a few questions though.
How can we go about extending this css plugin to do this?
Why just use postCss instead of node libs like node-sass or stylus
I've played with the css plugin to use the said plugins above with some minor errors around importing modules, but they seem to work.
as an example of an api that I think is clean, but will require more work on System.js:
import 'app/components/tab.styl!css!'
I like this because its clear whats happening. First are file is fetched an sent through the stylus plugin and then the result in injected into the css plugin.
We can start working on a fork plugin that can become a replacement for the CSS plugin.
The plan is to use postCSS because of the shared-parse tree it enables, which is the most efficient way of performing successive operations on CSS.
I'm not a fan of chained plugins for the exact reason as using postCSS - chained plugins don't share a parse tree so there is a cost of reparsing each step.
Rather I prefer to compose plugins as simple class extension / function composition:
It's also a more powerful syntax as you can more carefully share behaviours between plugins.
As for how to start, I'd suggest talking to @geelen as the work he's done on a CSS injection system is actually the best seed for a new CSS plugin like this.
There's also a bit of a discussion here about why we want blob URLs for dev: #25 (comment)
So, where my thinking is at is:
Have two methods of injecting CSS: BlobURLs (with sourcemaps, eventually) for devving in new browsers, style tags for old browsers and bundling
By default, only autoprefix the CSS, but do as @guybedford suggested and export hooks where you could change what's being processed. Passing in a list of postcss processors might be all we need.
Publish a couple of packs of useful postcss plugins (a bit like css next) as a way to get a bunch of functionality quickly, as well as an example of how to configure your own postcss combination.
Personally I think this issue should be re-opened. Geelen's project isn't maintained. Easy PRs aren't being pulled in which make it broken for use currently and not everyone who uses a default css plugin should have to use css modules. For instance, I can't easily import bootstrap css w/ Geelen's implementation, or, at the very least, it doesn't work out of the box compared to the current css plugin.
It looks MUCH simpler to just add postcss support to the current plugin.
So, I'm trying to get started with css-modules and postcss in jspm/systemjs but I am a bit confused about what is the current way to do this. Should I use @geelen jspm-loader-css, @MeoMix jspm-loader-css, or should I just make my own plugin that enables postcss somehow as per @guybedford's comments above? Also I saw a recent commits to this repo regarding postcss but that may not be related? Any guidance would be very appreciated...
My fork is much farther along than @geelen's. I got stuck trying to get cssnano to work properly. If you fork it and remove the cssnano logic then it should work fine (or did the last time I worked on it)
This project was updated in the last release to use postCSS for inlining, autoprefixer and minification support. These features don't run in the browser by default though.
@MeoMix I did a fork from your repo but not sure at what commit cssnano logic was added? I'm trying to find a commit to revert back to without cssnano as you mentioned above.
@MeoMix Thanks, got it working! At least composes works with external files, have not tried to make a separate css yet. If anyone wants to use it you can install it like this:
@MeoMix My original plan was to build on css-plugin-base in this repo, similar to plugin-less. Then I think we would get cssnano for free. It is easy to do, only there seems to be a bug in systemjs stopping it from working fully so I created this issue. However I guess all plugins will need to be rewritten for 1.0.0 of systemjs.
Gotcha. Sucks that SystemJS 1.0 only supports I.E. 11+. Was hoping to be able to bring all the fun to work, but we gotta support IE10. Anyway, good luck with the port! Sounds like you're on the right path and know what you're doing. :)
Activity
geelen commentedon Apr 1, 2015
Just to clarify, cleanCSS is currently only used when doing a
jspm bundle? I'd quite like to have at least autoprefixer running in dev mode, so was just about to look into this issue. Do you think it'd be worth starting a plugin-postcss project instead?Would the user have any control over which postcss plugins were being used?
guybedford commentedon Apr 2, 2015
Yes exactly - currently we only do operations at bundle time.
I do like the idea of moving to a compilation-based CSS workflow, and will happily get this plugin on board with that assuming all the dev hurdles can be conquered.
Global config options on the
Systemobject itself could enable CSS operations like auto-prefixing. Note that I'm not a fan of allowing any arbitrary operations though, as we can't have per-package configuration, so need to base it on a sensible baseline.In terms of creating more advanced compilation workflows into CSS (LESS / SASS / etc), this can be handled by composing other plugins with the CSS plugin (basically extending the CSS plugin).
The last issue is how to get this approach to work in IE8. For that, I guess we can forgo the debugging
<link>blob injection and just fall back to a more standard<style>injection.Hendrixer commentedon Apr 3, 2015
I would love to get started on this as I really need this feature. I have a few questions though.
postCssinstead of node libs likenode-sassorstylusI've played with the css plugin to use the said plugins above with some minor errors around importing modules, but they seem to work.
as an example of an api that I think is clean, but will require more work on System.js:
import 'app/components/tab.styl!css!'I like this because its clear whats happening. First are file is fetched an sent through the
stylusplugin and then the result in injected into thecssplugin.What do you think @guybedford ?
guybedford commentedon Apr 3, 2015
I'm not a fan of chained plugins for the exact reason as using postCSS - chained plugins don't share a parse tree so there is a cost of reparsing each step.
Rather I prefer to compose plugins as simple class extension / function composition:
less-plugin.js
It's also a more powerful syntax as you can more carefully share behaviours between plugins.
As for how to start, I'd suggest talking to @geelen as the work he's done on a CSS injection system is actually the best seed for a new CSS plugin like this.
Hendrixer commentedon Apr 3, 2015
hey @geelen, do you have any plans on getting started with any this? I want to get involved and make this happen.
geelen commentedon Apr 4, 2015
I've been basically hacking in-line on a new project, just to get a feel for the dev workflow before publishing anything. This is the simplest version I came up, with uses two post-css plugins,
nestedandautoprefixer: https://github.com/geelen/slabify/blob/e1469f0808eda102497f42ac43b3f0ac109bf92a/src/post-css.jsThat doesn't work in bundling, since the
createObjectUrlapi makes no sense outside of the currently-running browser, so I changed it to: https://github.com/geelen/slabify/blob/5232891617a5cc09eb624b24fd0c779bf0f05d20/src/post-css.js (I think I'll roll this back though)There's also a bit of a discussion here about why we want blob URLs for dev: #25 (comment)
So, where my thinking is at is:
Then we just need to make it lightning fast :)
chiefjester commentedon May 10, 2015
+1
XVincentX commentedon May 26, 2015
Any update/eta on this? I am really looking forward for the autoprefixer-dev mode.
geelen commentedon Jun 20, 2015
https://github.com/geelen/jspm-loader-css now includes Autoprefixer by default :)
guybedford commentedon Jun 22, 2015
As above, this feature will come with switching this project over to jspm-loader-css.
MeoMix commentedon Dec 22, 2015
Personally I think this issue should be re-opened. Geelen's project isn't maintained. Easy PRs aren't being pulled in which make it broken for use currently and not everyone who uses a default css plugin should have to use css modules. For instance, I can't easily import bootstrap css w/ Geelen's implementation, or, at the very least, it doesn't work out of the box compared to the current css plugin.
It looks MUCH simpler to just add postcss support to the current plugin.
guybedford commentedon Dec 27, 2015
Sure, I'd be open to a PR to update this project to PostCSS.
7 remaining items
guybedford commentedon Aug 21, 2016
Moving forward, this project can now be composed into more advanced CSS plugins, so keeping the core functionality simple for now.
guybedford commentedon Aug 21, 2016
(in other words a post-css plugin built on top of this one is trivial to build now, but I'm certainly not doing it anytime soon)
jonaskello commentedon Oct 10, 2016
So, I'm trying to get started with css-modules and postcss in jspm/systemjs but I am a bit confused about what is the current way to do this. Should I use @geelen jspm-loader-css, @MeoMix jspm-loader-css, or should I just make my own plugin that enables postcss somehow as per @guybedford's comments above? Also I saw a recent commits to this repo regarding postcss but that may not be related? Any guidance would be very appreciated...
MeoMix commentedon Oct 10, 2016
My fork is much farther along than @geelen's. I got stuck trying to get cssnano to work properly. If you fork it and remove the cssnano logic then it should work fine (or did the last time I worked on it)
jonaskello commentedon Oct 11, 2016
Ok so @geelen repo is out. @MeoMix I think maybe things have changed since the last commit on your repo which was in May? In August @guybedford said
Do you know what that is about? Also it seems both cssno and postcss are now dependencies in this repo so maybe it it built-in now?
guybedford commentedon Oct 11, 2016
This project was updated in the last release to use postCSS for inlining, autoprefixer and minification support. These features don't run in the browser by default though.
jonaskello commentedon Nov 2, 2016
@MeoMix I did a fork from your repo but not sure at what commit cssnano logic was added? I'm trying to find a commit to revert back to without cssnano as you mentioned above.
MeoMix commentedon Nov 2, 2016
@jonaskello MeoMix/jspm-loader-css@0923888 is where it was introduced.
jonaskello commentedon Nov 3, 2016
@MeoMix Thanks, got it working! At least composes works with external files, have not tried to make a separate css yet. If anyone wants to use it you can install it like this:
jspm install github:jonaskello/jspm-loader-css-meomixMeoMix commentedon Nov 3, 2016
@jonaskello Awesome to hear! :) I'll tip you five bucks if you can actually get cssnano working in production! ;)
jonaskello commentedon Nov 5, 2016
@MeoMix My original plan was to build on css-plugin-base in this repo, similar to plugin-less. Then I think we would get cssnano for free. It is easy to do, only there seems to be a bug in systemjs stopping it from working fully so I created this issue. However I guess all plugins will need to be rewritten for 1.0.0 of systemjs.
MeoMix commentedon Nov 5, 2016
Gotcha. Sucks that SystemJS 1.0 only supports I.E. 11+. Was hoping to be able to bring all the fun to work, but we gotta support IE10. Anyway, good luck with the port! Sounds like you're on the right path and know what you're doing. :)
guybedford commentedon Nov 8, 2016
@MeoMix good point. I actually just tested the 0.20 version and it does work in IE9+ I think.