Questions about the order of css @import

[bvanjoi]

version: 0.14.11

When I attempt to build following css files:

/* entry.css */
@import url('./lib1.css');

.entry {
  color: blue;
}

@import url('./lib2.css');

/* lib1.css */
.lib1 {
  color: red;
}

/* lib2.css */
.lib2 {
  color: green;
}

The result of esbuild entry.css --bundle:

And the result of esbuild entry.css:

Despite the warning alert, I still don't understanding why lib2.css had bundled, and even its order has changed.

According css @import rules defined by w3c, The results I expect to get is:

.lib1 {
  color: red;
}

.entry {
  color: blue;
}

postcss-import will also give the above result.

So my question is: why just warn, but not eliminate lib2.css ? Maybe it's for performance reasons, or maybe the order doesn't matter?

[evanw]

Yes, postcss-import behaves that way. Other tools such as Parcel behave the way esbuild currently behaves. I can make esbuild behave the way you want, since that is what the spec says. But I'm curious: why does it matter to you? What's your use case? Are you writing code that depends on invalid @import rules being dropped for correctness?

[hardfist]

We are migrating project which use postcss-import bundle css @import to esbuild and discover this inconsistency, Unfortunately users may depend on this behavior, so it would be really helpful if esbuild could align with postcss-import behavior(if this follows spec).

[evanw]

I'm planning to change this to pass invalid @import rules through unmodified instead of removing them. That's esbuild's general policy for invalid CSS (garbage in, garbage out) and since @import will no longer be recognized, it will now be treated as an unknown rule. This should still result in the behavior you want because it should be ignored by the browser, and by other CSS processing tools that behave the same way. And you'll still get a warning at parse time just like before. If you don't want invalid CSS rules in the output, I recommend removing them from the input.

[bvanjoi]

I'm planning to change this to pass invalid @import rules through unmodified instead of removing them. That's esbuild's general policy for invalid CSS (garbage in, garbage out) and since @import will no longer be recognized, it will now be treated as an unknown rule. This should still result in the behavior you want because it should be ignored by the browser, and by other CSS processing tools that behave the same way. And you'll still get a warning at parse time just like before. If you don't want invalid CSS rules in the output, I recommend removing them from the input.

Awesome work! Thank you very much.