css @import in incorrect context

[sbfaulkner]

we've run into a couple of issues with minifying (admittedly invalid) css

given...

.bad {
	@import url("other");
}
.red {
	background: red;
}

I'd hope an error, since @import isn't valid in that context, but can accept the produced result...
.bad{@import"other";}.red{background:red}

However, if we drop the ; from the import...

.bad {
	@import url("other")
}
.red {
	background: red;
}

We then get the invalid output (with an extra } at the end)...
.bad{@import url(other) } .red{background: red;}}

I've not been able to reproduce, but I have seen another case were we wind up with invalid css with extra ; after a number of rules.

Would it be possible to make the invalid "@import" an error?
(or possibly hav an option to do so)

[sbfaulkner]

I've reproduced the extraneous ; as well.
Given...

.bad {
	@import url("other")
}
.red {
	background: red;
}
.green {
	background: green
}
.blue {
	background: blue
}

The output includes extra (invalid) ; and } characters
.bad{@import url(other) } .red{background: red;}.green {background: green};.blue {background: blue}}

[evanw]

The reason this happens is that the } is considered to be part of the rule. This doesn't follow the specification, but esbuild already doesn't follow the specification because it supports parsing https://drafts.csswg.org/css-nesting-1/, which doesn't specify what to do here as far as I can tell. I'll try to improve this.

Would it be possible to make the invalid "@import" an error?

Since CSS specifies what happens when part of the syntax is invalid, invalid CSS is treated as a warning instead of an error. Also there are a huge number of ways CSS can be invalid and esbuild doesn't attempt to catch them. It mainly focuses on bundling. CSS validation is best done using alternate tooling such as a CSS linter.