Error with @charset and probably other at-rules
Closed this issue · 8 comments
The CSS minifier fails with the following message for CSS files that use e.g. @charset "UTF-8";
> Task :foo:minifyCSS FAILED
Error: @charset removed at base.css line 21 : 998
CSS Minifier: 1 error(s), 0 warning(s)
This seems to be related to (google/closure-stylesheets#103 (comment)).
Is there any way to ignore those at-rules?
The problem is that closure-stylesheets isn't developed anymore.
To get it running properly I had to release my own version and deployment to maven central is somehow broken.
So even if there was a fix for closure-stylesheets I might not be able to release it.
We could use the yuicompressor again. Maybe as an option so that one can switch between the compressors.
The problem ist yuicompressor isn't maintained either.
Do you know of another css compressor project?
Scratch that.
yuicompressor is not an option.
I will delete the closure-stylesheets pom and make my own so that I can reliably make new releases.
There is a TODO in closure-stylesheets to replace the error you're getting with a warning:
That can be easily done and I will release the new lib and replace it in this project.
The question is: it that enough to solve your problem?
If I understand it correctly the at-rule will be removed from the file. That is probably not what you want? You want to keep it right?
I can take a look if ignoring it is possible.
If you want you can look into it aswell and create a PR.
I will delete the closure-stylesheets pom and make my own so that I can reliably make new releases.
I had the same thought: If the project is actually dormant/inactive, I would fork it and start releasing it under my own GAV.
(Side note: I consider this a valid form of software evolution.)
There is a TODO in closure-stylesheets to replace the error you're getting with a warning:
That can be easily done and I will release the new lib and replace it in this project.
The question is: it that enough to solve your problem?
If I understand it correctly the at-rule will be removed from the file. That is probably not what you want? You want to keep it right?
Exactly. Those rules are there for a reason.
I can take a look if ignoring it is possible.
If you want you can look into it aswell and create a PR.
I'll try. Is the file you linked to above the place where it should be implemented? Would appreciate some pointer where to start.
I had the same thought: If the project is actually dormant/inactive, I would fork it and start releasing it under my own GAV.
The linked code is already my repository, released under my name (what's GAV?)
It's just that the deployment doesn't work anymore. Maven does not create source artifatcs and signatures.
But I will fix that
I'll try. Is the file you linked to above the place where it should be implemented? Would appreciate some pointer where to start.
I think it's a starting point. But it is probably too late in the chain. It seems the node has already been deleted at that point.
Although I did not see exactly where it is removed.
I have fixed the deployment. The source structure was weird and there was code generation which I couldn't migrate to gradle so I put the generated files in.
I also started to look at the issue.
You can look here if you want to help or have a starting point:
616slayer616/closure-stylesheets#1
There is a failing test that checks if the charset has been removed...
SImply reporting a warning instead of an error lead to an "unknown node" error.
So we will have to do it more complicated and actually handle the node.
Maybe this already works because I could run the minifier on a file with charset and it worked but I'm not sure.
Maybe you can test it?
The linked code is already my repository, released under my name (what's GAV?)
Group, Artifact, Version, which is the tuple that uniquely identifies an artifact in a Maven repository.
I think it's a starting point. But it is probably too late in the chain. It seems the node has already been deleted at that point.
Although I did not see exactly where it is removed.
I'm wondering why one would want to remove it anyway. What is the use case in which one wants to remove a @charset at-rule?
I have fixed the deployment. The source structure was weird and there was code generation which I couldn't migrate to gradle so I put the generated files in.
I also started to look at the issue.
You can look here if you want to help or have a starting point:
616slayer616/closure-stylesheets#1There is a failing test that checks if the charset has been removed...
SImply reporting a warning instead of an error lead to an "unknown node" error.
So we will have to do it more complicated and actually handle the node.Maybe this already works because I could run the minifier on a file with charset and it worked but I'm not sure.
Maybe you can test it?
Looking at the problem from a general point of view, I think a new option named allowedAtRules with a default of at least charset should be introduced. All rules that are in the list should be retained; everyone else should be "minified"; i.e., removed. This way one could configure the behavior w.r.t. those at-rules. What do you think?
Forget about that. It seems not so easy. I will further try to understand what is done in CreateStandardAtRuleNodes.java
I think I got it.
I had to add a lot of methods and used other @-rules as a guide.
Using this branch: 616slayer616/closure-stylesheets#4
I was able to get positive results with this branch of the minify plugin:
https://github.com/gradle-webtools/gradle-minify-plugin/tree/%2323-at-rules