Charset and variable declaration at file beginning lead to exception

[r-zander]

Hi there,

just started with Less4j today (via Wicket-Bootstrap-Less), so chances are good that my issue isn't really one - but at least Less.js behaved different than less4j and I wasn't able to find this behavior documented.

Wicket bootstrap less uses less4j like this:

ThreadUnsafeLessCompiler compiler = new ThreadUnsafeLessCompiler();
LessCompiler.Configuration configuration = new LessCompiler.Configuration();
configuration.getSourceMapConfiguration().setLinkSourceMap(false);
LessCompiler.CompilationResult result = compiler.compile(lessSource, configuration);
cssContent = result.getCss();

1st case: Stylesheet beginning with charset:

@charset "utf-8";

html,body {
    height: 100%;
}

Leads to

Caused by: com.github.sommeri.less4j.Less4jException: Could not compile less. 2 error(s) occurred:
ERROR file:/somepath/style.less 1:1 required (...)+ loop did not match anything at input '' in selectors (which started at 1:1)
ERROR file:/somepath/style.less 1:1 no viable alternative at input '' in ruleset (which started at 1:1)

How am I supposed to provide a charset for the stylesheet?

2nd case: Stylesheet starting with a variable:

@backgroundColor: rgb(255, 255, 255);

body {
    background-color: @backgroundColor;
}

Leads to the same error message(s).

3rd case: Variable declaration after some rule:

body {
    background-color: @backgroundColor;
}

@backgroundColor: rgb(255, 255, 255);

Finally works!

As I am new to less4j, the error message was not really helpful but after some tinkering I found out what's going on.

[SomMeri]

Hmm, that is weird, your examples work for me (similar file compiles on travis too). Could you please put breakpoint on the line

LessCompiler.CompilationResult result = compiler.compile(lessSource, configuration);

and check output of lessSource.getContent(); at that point? Maybe something modified file you are compiling before it hit less4j.

[r-zander]

I checked the content - it's the same as in my file.

But I think I found the cause: My cases behave like this if you have a BOM in the beginning of your file (as I usually have). Without BOM (but still in UTF-8 encoding) everything works fine. Is this a supposed behavior? I always thought that UTF-8 files should start with the BOM.

[martin-g]

No one likes BOM. We use https://github.com/apache/wicket/blob/master/wicket-util/src/main/java/org/apache/wicket/util/io/BOMInputStream.java in Wicket to remove the BOM before reading the markup files.

[SomMeri]

I would rather not to deal with BOM, so I will close this as "wont fix". If anyone disagree, feel free to make your case either here or in a new issue and I will reconsider my position.