Anthon Pang

https://docs.saucelabs.com/dev/api/

sjcl.encrypt() broke because the default iv was 16 bytes: * https://github.com/bitwiseshiftleft/sjcl/blob/master/core/convenience.js#L28 ``` var j = sjcl.json, p = j._add({ iv: sjcl.random.randomWords(4,0) }, j.defaults), tmp, prp, adata; ```

LGTM. Would you maintain a feature branch until the first built-in module/function can be parsed and evaluated, or would you release things (eg parser changes) as they're implemented? Is there...

Sounds good to me. `scssphp2` was just a placeholder name.

By "plan", do you mean something more concrete than a wish/todo list? ;) Off-hand, implementing `@use`/`@forward` looks non-trivial.

Sass-spec compatibility is a primary project goal. There's no immediate plan to report the sass-spec results in travis though. Compatibility issues are generally addressed as they're encountered with popular scss...

Just saying that once it's a pecl package, there's more likelihood that it later becomes a distro package, which then becomes much easier for webhosts to install.

But that's moot... I see Ubuntu already has https://github.com/absalomedia/sassphp packaged up starting with bionic. * https://packages.ubuntu.com/bionic/php-sass

First of all, I am very thankful of your combined contributions (@stof and @Cerdic) to this project. If I'm not mistaken, this RFC is a hybrid of paths 1 &...

I'm leaning towards #1 for this library. I like the idea of #2 but agree that it will take resources to develop and maintain (as dart-sass evolves).