Node-sass: V3.5.3 `failed to @extend`

[esbanarango]

I'm getting this error with the last version:

Use "@extend .ui-header !optional" if the extend should be able to fail.
at options.error (/Users/esbanarango/myProject/node_modules/ember-cli-sass/node_modules/broccoli-sass-source-maps/node_modules/node-sass/lib/index.js:271:32)

[sethbrasile]

Prior to 3.5.0-beta.1, extending a css selector that didn't exist until runtime was possible. 3.5.0-beta.1 through 3.5.3 does not allow this. Is this a bug, or is !optional now required?

[sethbrasile]

Looks like it's probably related to https://github.com/sass/libsass/issues/1670 @esbanarango, we may need to open the issue over there. Doesn't seem like a css class should be considered an "undefined placeholder"

[sethbrasile]

You know.. I'm going to investigate a little further, but I'm thinking this is actually a "feature." I think it's catching a "bug" that we didn't know existed. Will report back.

[mgreter]

@sethbrasile I think your spot on with that assessment ;)

[kylecesmat]

@sethbrasile This is a feature, I agree. but it has broken a lot of my builds. Going from silently failing to now throwing errors should've warranted a higher version bump IMO.

[sethbrasile]

Verified that this is a feature :D

with 3.4.2:

.header {
  @extend .ui-header;
  color: $light-blue;
  margin-bottom: 1.5em;
}

gets compiled to:

.header {
  color: #9CC1E4;
  margin-bottom: 1.5em;
}

So it's just pinpointing that we're doing something stupid. But agree nonetheless, should have been a major version.

[mgreter]

I can understand your point somehow, please also see my other comments.
node-sass was always clear that it will not follow semver if libsass changes in a way that is more in line with official ruby sass (and this includes errors obviously). So that's the contract. You can still pin node-sass to a specific version if you don't have the time to fix your code, which should be quite trivial. Silently ignoring stuff is really uncool for people that convert from ruby sass to libsass. That's all I have to say, as I'm not a maintainer of node-sass, so technically that's not even any of my business.

[sethbrasile]

Sorry @mgreter 😢

Totally understand, broken builds are just always such a surprise 😱

I think what we're experiencing here is just kind of "par for the course" with the current package eco-system, dependencies of dependencies of dependencies and all that 😃

[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.