Build fails with "Expanded null selector" error

[amageed]

I originally asked this on the ember-cli-sass project and was directed here since it's most likely node-sass related. Here's my question reproduced from my original post on ember-cli-sass.

I recently added ember-cli-sass and had Sass working fine on one machine. I cloned my repo on a different machine and ran into this issue. The code is the same, cloned directly from the repo.

When I run ember build I get:

version: 1.13.1
Build failed.
Expanded null selector
Error: Expanded null selector
    at options.error (/Users/amageed/code/emberproject/node_modules/ember-cli-sass/node_modules/broccoli-sass-source-maps/node_modules/node-sass/lib/index.js:277:32)

A blank app.scss file gives no error, but any CSS content causes this error to occur.

I'm not sure what could possibly be different between both machines and their setups. They're both running the same versions of node, and all dependencies are coming straight from what I had defined in package.json and bower.json. A co-worker was also able to clone the repo and had a successful build.

I'm on Node v0.12.7 (npm 2.11.3), ember-cli 1.13.1, ember 1.12.1.

I've tried completely removing node and associated folders, and reinstalling the dependencies from npm/bower to start fresh but there was no difference.

Any ideas?

[saper]

Can you post a pure, self-contained scss file that causes this error against node-sass?

[amageed]

@saper it doesn't seem like node-sass on its own is the problem. I installed node-sass directly via npm and when I run it against my Sass files it works perfectly.

The problem I'm running into seems to exist as part of the ember-cli-sass process when I run ember build. Something as simple as the following plain CSS in an app.scss file gives me the error:

.app-header {
  left: 0;
  top: 0;
  position: absolute;

  .actions {
    position: relative;
    top: 8px;
  }
}

Again, what's bizarre is that this is only limited to one of my computers and works fine on another. I'm not sure what else to compare to narrow down the root cause.

Sorry if this isn't really relevant to node-sass.

[saper]

Unfortunately I don't know how to further work on this without some sample code. Any differences between machines? Platform, 32 bit vs 64 bit, node versions, C++ library versions?

[eoneill]

I'm seeing this issue as well with 3.4.2, and it's similarly hard to narrow down what's going on.

What I have so far...

In one project (using eyeglass and node-sass@3.4.2) I can reproduce this issue consistently with the following sass:

@at-root %foo {
  color: red;
}

In another project, also using the same version of node, eyeglass and node-sass, the above compiles fine.

Similarly to the above report, rm -rf node_modules && npm clean cache && npm install or even a fresh checkout doesn't fix the issue.

The failing project is significantly more complex with more dependencies, so I'll continue to work on getting a minimal reproduction case.

For the curious, my failing project is eyeglass-restyle. You should be able to reproduce most of the tests failing with Expanded null selector by changing the node-sass version to 3.4.2 (currently passing with 3.3.3).

[eoneill]

Hrm, interestingly, I'm not getting that error on the travis build: https://travis-ci.org/eoneill/eyeglass-restyle/builds/91548438

But I can reproduce this issue locally on OSX. Here's what I see locally: https://gist.github.com/eoneill/a7e93f0769f35b1f7688

Will keep digging.

[saper]

@eoneill when I try to npm install your project on my FreeBSD system something insists
on installing node-sass@3.3.3 alongside with 3.4.2:

> node-sass@3.4.2 install /home/saper/node_modules/eoneill/eyeglass-restyle/node_modules/eyeglass/node_modules/node-sass
> node scripts/install.js

Binary downloaded and installed at /home/saper/node_modules/eoneill/eyeglass-restyle/node_modules/eyeglass/node_modules/node-sass/vendor/freebsd-x64-47/binding.node

> node-sass@3.3.3 install /home/saper/node_modules/eoneill/eyeglass-restyle/node_modules/node-sass
> node scripts/install.js

Cannot download "https://github.com/sass/node-sass/releases/download/v3.3.3/freebsd-x64-47_binding.node": HTTP error 404 Not Found

> node-sass@3.4.2 postinstall /home/saper/node_modules/eoneill/eyeglass-restyle/node_modules/eyeglass/node_modules/node-sass
> node scripts/build.js

` /home/saper/node_modules/eoneill/eyeglass-restyle/node_modules/eyeglass/node_modules/node-sass/vendor/freebsd-x64-47/binding.node ` exists. 
 testing binary.
Binary is fine; exiting.

> node-sass@3.3.3 postinstall /home/saper/node_modules/eoneill/eyeglass-restyle/node_modules/node-sass
> node scripts/build.js

(compilation follows)

from the quick look at the npm tree:

eyeglass@0.6.5 node_modules/eyeglass
├── semver@4.3.6
├── tmp@0.0.27 (os-tmpdir@1.0.1)
├── fs-extra@0.23.1 (path-is-absolute@1.0.0, jsonfile@2.2.3, rimraf@2.4.3, graceful-fs@4.1.2)
├── glob@5.0.15 (path-is-absolute@1.0.0, inherits@2.0.1, once@1.3.2, inflight@1.0.4, minimatch@3.0.0)
├── deasync@0.1.4 (bindings@1.2.1, nan@2.1.0)
├── lodash@3.10.1
└── node-sass@3.4.2 (get-stdin@4.0.1, async-foreach@0.1.3, chalk@1.1.1, nan@2.1.0, mkdirp@0.5.1, npmconf@2.1.2, gaze@0.5.2, cross-spawn@2.0.0, meow@3.6.0, sass-graph@2.0.1, request@2.65.0, node-gyp@3.1.0)

node-sass@3.3.3 node_modules/node-sass
├── get-stdin@4.0.1
├── async-foreach@0.1.3
├── chalk@1.1.1 (escape-string-regexp@1.0.3, supports-color@2.0.0, ansi-styles@2.1.0, strip-ansi@3.0.0, has-ansi@2.0.0)
├── nan@2.1.0
├── mkdirp@0.5.1 (minimist@0.0.8)
├── glob@5.0.15 (path-is-absolute@1.0.0, inherits@2.0.1, once@1.3.2, inflight@1.0.4, minimatch@3.0.0)
├── npmconf@2.1.2 (ini@1.3.4, uid-number@0.0.5, inherits@2.0.1, once@1.3.2, semver@4.3.6, osenv@0.1.3, nopt@3.0.6, config-chain@1.1.9)
├── gaze@0.5.2 (globule@0.1.0)
├── meow@3.6.0 (trim-newlines@1.0.0, object-assign@4.0.1, minimist@1.2.0, camelcase-keys@2.0.0, loud-rejection@1.2.0, redent@1.0.0, normalize-package-data@2.3.5, read-pkg-up@1.0.1)
├── cross-spawn@2.0.0 (cross-spawn-async@2.0.0, spawn-sync@1.0.14)
├── request@2.65.0 (aws-sign2@0.6.0, forever-agent@0.6.1, tunnel-agent@0.4.1, oauth-sign@0.8.0, caseless@0.11.0, stringstream@0.0.5, isstream@0.1.2, json-stringify-safe@5.0.1, extend@3.0.0, tough-cookie@2.2.1, node-uuid@1.4.7, qs@5.2.0, combined-stream@1.0.5, form-data@1.0.0-rc3, mime-types@2.1.7, http-signature@0.11.0, hawk@3.1.1, bl@1.0.0, har-validator@2.0.2)
├── node-gyp@3.1.0 (graceful-fs@4.1.2, semver@5.0.3, osenv@0.1.3, nopt@3.0.6, minimatch@1.0.0, fstream@1.0.8, which@1.2.0, glob@4.5.3, tar@2.2.1, path-array@1.0.0, rimraf@2.4.3, npmlog@1.2.1)
└── sass-graph@2.0.1 (yargs@3.30.0, lodash@3.10.1)

Why do you insist on using node-sass@3.3.3 in your devDependencies and mix the two?

[eoneill]

I hardcoded to 3.3.3 because 3.4.0 and 3.4.1 initially broke eyeglass.

I'm going through my projects making sure they work with 3.4.2 now.

In this case, 3.3.3 is not used, as I explicitly pass the 3.4.2 engine into eyeglass-dev-testutils.

[eoneill]

Ok, so good news. Things are now consistently passing for me after removing node-sass@3.3.3 from eyeglass-dev-testutils.

This still seems like something is leaky here. If I add node-sass@3.3.3 to a random dependency and then require("node-sass"), it fails again.

The odd thing is that this second instance of node-sass is not used in any way, but it still causes the above issue. Removing the unused require statement and it works again.

This would suggest that libsass is leaky and having an active instance of two different versions will cause issues.

[amageed]

@saper all the versions seem to be the same for OS, node, etc. I did have a co-worker successfully install the project on a Linux VM, whereas the error was occurring on OS X. Still need to dig into the differences between machines after Thanksgiving.

That said, the feedback from @eoneill was helpful. It turns out one of the Ember-CLI addons we're using uses a different node-sass version than the version broccoli-sass uses as a dependency. If I modify that addon's package.json to use the same version and remove the node_modules and npm install again, everything works fine.

I might have to use npm shrinkwrap to get around this, or ask the addon devs to make the node-sass dependency more flexible.

[xzyfer]

From what I can discern from reading this issue is that npm was deduping node-sass to an older version. The older version was causing Sass code to error due to a known issue fixed in recent a recent version.

If this is the case then I don't believe there is anything that can be done from our end.

[eoneill]

I don't think that's necessarily the case. The scss I had compiles fine in 3.3.3 and 3.4.2. But when both version were loaded within the same execution run, it would error out.

This happened because a dependency had a fallback version of node-sass locked at the older version (3.3.3).

e.g.

module.exports = function doSomethingWithSass(sass) {
  // if you comment this line out, everything works
  sass = sass || require("node-sass"); // `node-sass` here was pinned at 3.3.3
}

var doSomethingWithSass = require("do-something-with-sass");
var sass = require("node-sass"); // 3.4.2
doSomethingWithSass(sass);

If that doesn't make sense, lemme know and I think I can create a minimal repo to reproduce.

[saper]

@eoneill I think it would be a good idea to file a bug against npm here. I am not sure why this happens and what we could do to improve the situation. We are using require and require.resolve to find our modules.

[xzyfer]

@eoneill I'm not sure that this is something we can control. What you do you think we should do differently in your case?