Joint plugin development about postcss-import HOT 12 CLOSED

I think postcss-import already inline @import even if they are not at the beginning of the file. So this part should be ok (I hope I understand your point correctly).

For the rebase of assets it's a really good idea but imo, it doesn't need to be a postcss-plugin.
postcss is a library to parse & work on stylesheets only.

That being said, we can totally create & use a library simpler library in postcss-import to offer this feature (rebase and/or copy of assets in another place).

from postcss-import.

Hi. Sorry, I didn't mean exactly this things. :) I think examples will help.

Then I write about css rebase I mean changing paths to assets, not moving assets themselves.

Example directory structure:

css-with-bg/
  css-with-bg.css
  bg.png
css-with-import.css

css-with-import.css content:

@import "css-with-bg/css-with-bg.css";

css-with-bg/css-with-bg.css content:

.selector {
    background: url( "bg.png" );
}

If we just include "css-with-bg/css-with-bg.css" to "css-with-import.css" then link to file "bg.png" will be broken. It is a big problem then you use BEM methodology for example – they have each css and it's images in separate folders.

So then you include file content you have to change all relative url() values to the new directory root.

About @import rules.

The problem is following: Browser only reads @import rules if they are in the beginning of the file or after @import and @chaset rule.

So if for some reason we cannot include @import value to the file AND we already included some value before it, then browser will just ignore @import rule and will not try to import it anymore.

Example.

Original file:

/* Local file with relative path, we can include it.*/
@import "local.css";
/* CSS with path from server root. We can't include it. */
@import "/another.css";
/* External CSS. We can't include it. */
@import "http://google.com/style.css";

This code is working because there is only @import rules in file. BUT if we now include first file AND leave second and third as @imports, THIS they will stop working because there is now css rules before them.

Browser will not load imports from this file:

/* We replaced first file with it's value. */
.local { color: red; }
/* Will not be loaded by browser. */
@import "/another.css";
/* Will not be loaded by browser. */
@import "http://google.com/style.css";

We can fight this problem a number of ways:

1. We can move unresolved @import rules to the top of the file. It will make them work, but it can potentially broke user's css, because we changed css order.
2. We can leave them as is and throw warning about it.
3. We can start including @imports not from the top, but from the bottom, and stop including after we wasn't able to include a file.

I want to make third option default, but make it possible to select 1 and 2.

from postcss-import.

Thanks for all those clarifications.

For the assets I totally get your point, but for example, currently, I end up with a dist/ folder where are my public files, so just rebasing urls will not be enough for be (for now I just copy all "static" files in my dist/ folder, I don't have that much). That why I said rebase AND/OR copy. I think this 2 feature should work together (obviously optional).

For the @import: OMG this is horrible (I never @import http files so didn't know about that... shit ? :D ). I would go for 1 since in a lot's of people already put @import at the beginning but here is (I think) a more possible case

@import "foo.css"
@import "bar.css"

foo.css

html { /*...*/ }

bar.css

@import "http://google.com/style.css";
/* whatever */

Without this plugin, code above will work, but this will (for now) give us (if plugin used)

html { /*...*/ }
@import "http://google.com/style.css";
/* whatever */

which, as you said, will broke the external import.
In this case a simple move at the top should be enough (and I think 95% of the time this should be ok, since not a lot of people are importing http files, except maybe for fonts ^^).

solution 2 can be an option, but this is totally not helping end user (except telling him he should totally refactor his code :/)
solution 3 sound seem the worst :/ (if you use a build process & a public folder, you have a lot of chances that local non imported files will not be available from here).

I'm seeing postcss-import as a special plugin that should be done before anything else & think it's important to have something logical for the end user: @import should just "work as expected" (no warning or non imported file if you want a solution to inline all the @imported file).

That being said, I'm sure we can find a way to make everybody happy :)

from postcss-import.

Rebase is only one of possible way to work with assets. I'm usually just insert them as data uri. So for me build process looks like this now:

1. Make one css file.
2. Replace images with data uri.

So I think data-uri utility and rebase utility must be separate plugins.

So, about this two tasks. How do we make them work? I can clone project and try to add my helpers and url-modification plugin there, but it looks they are partially repeating "find-file" and "parse-import". What is the best way to avoid conflicts and duplicate functionality? Maybe you can look at the plugins at the above links and see what is the best way to use it?

P. S. I'll probably only able to do it at the end of the week. :(

from postcss-import.

I'm not in the hurry.

Hey interesting thing. What if, instead of making 2 step, we IMPORT everything in the postcss-import plugin directly ?
This will avoid a lot of unnecessary work, especially if you using this 2 steps all the time.

from postcss-import.

Well, actually I already written all it once before and it was hell to support. :) So now I try to make it modular as strong as I can. So I think to make a lot of separate plugins first and then wrap them in single standalone utility.

My previous attempt:

• http://github.com/jetstyle/grunt-styletto
• https://github.com/jetstyle/styletto

from postcss-import.

P. S. Also tried to write rebase plugin before, but that attempt failed miserably: https://github.com/iAdramelk/grunt-cssrb Even I have to look at the code every time I want to remember how to configure it.

from postcss-import.

I get your modular point. I've done the same for postcss-calc (which use reduce-css-calc (which use reduce-function-call)).
I just think you can do a lib that not depend on postcss whenever it's possible.
I would go for using find-file to find the assets (for a given declaration) & a lib that convert to base64. I think this approch should be quick & not adding too much code. Don't you think ?

I'm creating an issue for moving http import at the top.

from postcss-import.

Yes, I try to do the same. I use URIjs in postcss-helpers because I didn't want to think about all this http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding .

So the main principle of separating plugins for me right now is "Can it be used separately and still be useful?".

from postcss-import.

We need to find the appropriate middle between KISS & reusability. I think for now we can do that pretty quickly with just a few lines of code. Maybe I'll try to do that before you do :)

from postcss-import.

Cool. I'll then try to add url() rewriting part for now, because I really need it to use plugin in everyday work.

from postcss-import.

So I'm adding another issue to handle the rebase for assets. #3

from postcss-import.