semver

[callumacrae]

Are you using it?

There were breaking changes in 3.1 (not mentioned in the release notes! see sass/libsass#489 (comment)), which was unexpected because you haven't said you're not using semver. It would be great if you could either start using it, or add a little note to the README saying to be aware that you're not using it :)

[xzyfer]

Hi @callumacrae, yes, we strictly follow semver.

The breaking change question was introduced in node-sass@3.0.0 and libsass@3.2.0 and was clearly communicated in both changelogs

• https://github.com/sass/node-sass/releases/tag/v3.0.0
• https://github.com/sass/libsass/releases/tag/3.2.0

There were also a handful of beta releases with this breaking change implemented.

[callumacrae]

Is "Remove image path options which are no longer supported by Libsass" referring to this? I feel that could be clearer!

Fair enough, though. I guess I just read the changelog too quickly.

I'd argue that you still broke semver, though—this was a breaking change on a minor version. Even if it was documented earlier, a developer should be able to update straight from 3.0.0 to 3.x.x without having to make any code changes. The best approach imo would have been to have deprecation notices from 3.2.0 letting people know that they shouldn't be using it—but not removing the functionality—before actually removing it in 4.0.0.

[geekdada]

I can write my own image-url function, but I need a dynamite variable to alter the output. Is there any handy way that can pass different variables to Libsass based on the compiling environment settings?

BTW, I don't wanna switch to Compass...

[xzyfer]

@callumacrae this feature was removed in node-sass@3.0.0, a major. Libsass does not follow semver. This is on purpose as per their Compatibility Plan .

The node-sass team manage our version to account for changes in Libsass i.e.

• if they introduce a breaking change we bump the major
• if they introduce a feature change we bump the minor
• if they introduce a bug fixes change we bump the patch

I agree deprecation notices would be ideal, and this happened in a beta. However the deprecation implementation was cause other issues for users. The Libsass team does not have internal framework for deprecations since their goal is stability by 3.4 (not before).

In the end we made the decision to remove feature since as far as we could ascertain the usage was low, and the time required to build a better deprecation mechanism would have further delayed a critical release. This was a judgement call by the Libsass and node-sass teams but we're sorry you were inconvenienced.

[xzyfer]

can pass different variables to Libsass based on the compiling environment settings

@geekdada technically no. This has been suggested to the Ruby Sass team before and they have decided not to do it. For now the way I solve this is to use includePaths.

// config/production/_settings.scss
$image-path: "/foo/bar/baz";

// config/dev/_settings.scss
$image-path: "/foo";

// index.scss
@import settings;
@debug($image-path);

require('node-sass).renderSync({
  loadPaths: [
    process.env.DEV ? 'config/dev` : 'config/prod`,
  ]
});

---

This works because when you @import settings the settings file does not exist in the current directory. This means we need to look in the loadPaths for the settings file. By changing the load paths we can control which settings file gets loaded.

[geekdada]

@xzyfer It works :)

THX

[thabti]

+1 awesome