Closed monomadic closed 7 years ago
After more exploration, if I go through the step of converting the code to scss before running the compiler, it does work, so this is a nasty workaround/hack, but it works. It also further shows that it's definitely lack of sass support.
func (p SassProcessor) compile(tpl *TemplateWriter) error {
buffer := new(bytes.Buffer)
err := libsass.ToScss(tpl.buffer, buffer)
if err != nil {
return err
}
compiler, err := libsass.New(tpl.writer, buffer)
if err != nil {
return err
}
return compiler.Run()
}
Both are supported. The short answer is that Sass and SCSS are ambiguous and it's not possible to determine one from the other 100% of the time. Code can be crafted that is both SCSS and Sass. libsass makes you choose which style you are providing, that's why they prefer working only on files where the extension is specified .sass or .scss
A new compiler option to instruct the compiler that Sass is being sent is needed here. Like how this works https://godoc.org/github.com/wellington/go-libsass#HTTPPath ... maybe nix the ToScss public method since a compiler option would be more useful.
Wellington sniffs the stream and attempts to determine which type of code is being sent: https://github.com/wellington/wellington/blob/master/import.go#L30-L45
Agreed, an option
passed to the compiler would be great.
Your explanation makes a lot of sense, thanks.
Am I wrong in assuming this library does not support sass? And instead only supports scss? All of the tests are scss only, so perhaps it's broken, but only scss will compile.
Reproducing the problem: a sass file with this, for example:
Will produce the following error: