Node-sass: Node-sass made a breaking change without tagging a major version update

[dclowd9901]

The reason semver exists, and is important in public modules is that if you make a change that breaks functionality, consumers of the module won't immediately pick it up by opting into minor or patch changes.

Yesterday, node-sass updated to 3.5 and with that change, fixed a bug that allowed users to declare a function inside of a conditional clause. Fixing this bug would break any code that declared functions in conditional clauses, which is exactly what happened in compass-mixins.

In the future, when code is shipped that could potentially break code, it needs to be shipped under a major version update.

[brandonburkett]

had this same issue 💔 went back to "node-sass": "~3.4.2"

[fenduru]

This is also currently biting my project, which uses gulp-sass. gulp-sass depends on node-sass#^3.4.1 which just automatically updated to 3.5.3 which is a breaking release.

[xzyfer]

This project is an implementation of the Sass language. Our goal is to be 100% compatible with Sass. These issues you mention are a result of invalid Sass. Node Sass has no way to know that these breakages because we assume valid Sass is being compiled. This is no different to depending on an undocumented API. For that reason we do not consider these breaking changes.

If valid Sass started breaking we would consider that a breaking change. We don't claim responsibility for bugs in the Sass code being compiled.

If you wish to suggest features of file bugs in the Sass language please open an issue with Sass - https://github.com/sass/sass

In closing if your code does not compile with the official Sass project you should not expect it to compile with Node Sass.

[xzyfer]

I have blogged about this for more details - https://medium.com/@xzyfer/why-node-sass-broke-your-code-and-semver-1b3e409c57b9

[dclowd9901]

I understand and appreciate the goals of node-sass and this is my attempt to contribute. If you fix something that's broken (e.g. A bug that allows invalid code to no longer compile) that is considered a major change under any interpretation of semver. I only ask that maintainers consider changes and version tagging more closely. If they need help, feel free to add me to the list of maintainers.

[nschonni]

Since you bring up SemVer, see this point http://semver.org/#spec-item-6 emphasis

A bug fix is defined as an internal change that fixes incorrect behavior.

[dclowd9901]

@nschonni you seemed to have accidentally left out this first part of that section "Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced."

[xzyfer]

@dclowd9901 you're missing an integral part which I covered in my blog post. There is simply no way we can know we're breaking invalid Sass code. It's impossible to account for every possible thing or combination of things someone is trying to compile as Sass.

We expect that the code being compiled is valid Sass code. If we break valid Sass code it's a breaking change. If your code was invalid we cannot make any guarantees.