Created an @import disk read plugin (#24). It just goes in a depth first search and merges the css ast into current one. Not sure if it's the way you'd want to implement though. Feels kinda ugly.
.import(basePath) plugin to read and inline @imported stylesheets
+1000 for this feature, haven't had a chance to look at your implementation.
It will need for me too, to move from Sass :).
Maybe we need different keyword @include 'path'? But for me it’s OK now :).
Why does it need to be a different keyword? It'd be cool to have plugable name resolution so that you could do a node.js/npm style lookup of installed css.
@ForbesLindesay it is just idea :-).
Real problem, that plugin must lookup in several dirs. For example, Rails has a lot of assets dirs.
+1 On the necessity of this plugin.
Any feedback yet on what would be needed to merge it?
I wouldn't mind this one being a third-party plugin as well as far as the lookup techniques etc go, I don't think many people actually use vanilla @import anymore but there's also that being a collision as an issue. I wouldn't mind @import foo, @import ../foo/bar etc as things we touch and quoted ones remain vanilla, tough call. It also depends on the extname too, we use .styl because of css-whitespace and our stylus syntaxes
Are you saying you would be ok with:
@import ../fwee imports fwee.css and fwee.styl for inclusion in the current rework
@import "../fwee" or @import url("../fwee") would do the seldom used vanilla import
Does this work?
I feel like anyone interested in using rework would probably not be using vanilla imports though no?
Personally I'd much rather we handled the string based version. I.e. optimise the vanilla case so it can actually be used.
@ForbesLindesay I think we are talking about two flavors of "vanilla" here. For clarity the one I am talking about is the worst practices one where the @import URL is included by the browser. I feel that for this case it would be best to basically concat the files when reworked since most people would not want multiple http requests and each browser does something different with it.
There is a cool recommendation for the @import where you can specify which CSS file to load for the browsers current media query, but it isn't implemented and in its current state would slow page load a bit anyways. Rework could support this recommended functionality *somewhat by creating an @media block from the information in the @import https://developer.mozilla.org/en-US/docs/CSS/@import.
An issue with just adding the contents of another file is that rework processing starts to become order dependent, which I don't think is wanted. For instance if each file has a variable block at the top you need to make a call as to how to define scope. A common pattern I see with stylus users is they have their variables in a separate file all together and import them into files that use them. In the current rework spec I am not sure how this would work. Would you require duplicating variable definitions at the top of each file then process the variables at import time before inclusion? Would you merge variables? Would it be last in wins as far as overriding variable values?
leaving out of core for now
I actually think you could get away with not needing this if you're using something like Component. If your CSS is really modular you could probably get away with not caring about the order of the files and just concat everything and run Rework over it.
yea you can definitely get away from it with a small makefile or other build tool. for some plugins like vars you'd have to do a single pass otherwise you lose all that data though hmm..