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.
Reusing substack/insert-css #25
Description
Was getting started on my postcss loader just to get a feel for how to write a loader. Came up with this, which in dev mode seems to work just like plugin-css:
import insertCss from 'insert-css'
export var translate = (load) => {
insertCss(load.source)
load.source = ''
}The biggest change I can see is that cross-domain CSS can be loaded from a link[href] but the default fetch var uses XHR which would blow up. Is that a big deal?
Anyway, I wanted to start a thread about whether it'd be worth rewriting plugin-css to reuse as much already out there as possible. It was the first thing I read when I tried to understand the plugin system, and it lead me astray a bit. I didn't realise you could write plugins in ES6, for instance.
Activity
guybedford commentedon Apr 1, 2015
Originally when I was working on https://github.com/guybedford/require-css/, I used to use a similar injection method but there were issues with this:
The last two (and really just the last one actually) are the main reasons really.
The injection code does still need to be supplemented with old IE support, which is also hiding in https://github.com/guybedford/require-css/blob/master/css.js waiting to be ported.
This plugin hasn't been given as much attention as it needs though, I do realise. Thanks for showing an interest in this stuff!
guybedford commentedon Apr 1, 2015
Scratch everything I just said.... your point on auto-prefixing makes sense now.
How is the debugging experience looking these days with this approach?
geelen commentedon Apr 1, 2015
Well it's pretty slow! This is me using https://github.com/postcss/postcss-nested and https://github.com/postcss/autoprefixer:
So that's taking 2 seconds to load the files to compile this much CSS:
But this is a very naive implementation, but I'm just sort of exploring at the moment. I thought about maybe using https://github.com/medialize/sass.js/ but for my stuff I don't really need all of SASS. Just autoprefixer, really.
I might try using this next: https://raw.githubusercontent.com/ai/autoprefixer-rails/master/vendor/autoprefixer.js. It's a single-file version, I imagine it'll simplify things hugely.
geelen commentedon Apr 1, 2015
Of course, I just realised the plugin can be published after being built
into a single file - there's no need to load up the plugin's dependencies
one by one...
On Wed, 1 Apr 2015 at 7:09 pm Guy Bedford notifications@github.com wrote:
geelen commentedon Apr 1, 2015
Interesting, by using
jspm build --injectI can take the total number of files loaded from 166 to 13. It takes the performance from this:to this:
This is hosted on Surge, not local btw, so you can better see the difference. I didn't realise how pro
--injectwas :)guybedford commentedon Apr 1, 2015
Yeah that can often be a good dev workflow. Btw you can do
jspm bundle app/**/* - [app/**/*] -ito automatically bundle everything not in app.Specifically when I asked about the debugging - the argument before was that we want to be able to see the line numbers in the CSS file for debugging, that's why we tried to stick with
<link>tags. Do you know if this is working better for<style>approaches now? Have the sourceURLs improved enough now to enable this? Would be the make or break for me.geelen commentedon Apr 2, 2015
Holy what? What kind of wizardry is
jspm bundle app/**/* - [app/**/*] -i! That's crazy!As for your other question, I'll keep chipping away at this project today using this workflow, see how it feels.
I did have a related question for you though - if I wanted to publish a
plugin-autoprefixermodule, that was as simple as https://github.com/geelen/slabify/blob/24f0568f07736c4e66f6048b3762f42593637775/src/postcss.js, can I ship it 'pre-bundled'? So that by default, adding theautoprefixerplugin only added 1 extra file to your dev workflow, rather than 150+?I started to understand the bundle format last night, I can't believe how simple it is — just a collection of
System.registercalls. I assumed there'd be all this boilerplate like in a browserify bundle or like inbuild-sfx. So the bundle format is probably sufficient, but I'd need whatever I publish to inject the bundle definitions to the user's project. Something like:That make any kind of sense?
geelen commentedon Apr 2, 2015
Yeah ok this isn't ideal:
I'll see if I can figure out a way to use a
<link>tag instead but still doing all the work intranslate.geelen commentedon Apr 2, 2015
Success! By making use of
URL.createObjectURL, I can do the transformation & inject<link>tags. This is what you get:Clicking on the top one:
Theoretically we should be able to get source maps working here, right?
guybedford commentedon Apr 2, 2015
Awesome!! I think source maps would definitely work with that via a sourceURL comment using another blob URL or data-URI. This sounds like it might well be a viable dev workflow then.