Add a way to list discovered modules for debugging purposes

[kohlmannj]

Per my lament on Twitter, it'd be great if the Eyeglass instance had an attribute or method to list the Eyeglass modules it knows about (and some other information, like their file paths).

[kohlmannj]

Added thought: debug output for known functions and Sass paths per named Eyeglass module would be good, something like:

"modules": {
    "eyeglass-sample": {
        "version": "0.0.3",
        "sasspath": "node_modules/eyeglass_example/sass",
        "functions": [
            "hello($name)"
        ]
    },
    "susy": {
        "version": "2.2.6",
        "sasspath": "node_modules/susy/sass"
    }
}

[kohlmannj]

Also adding what I noted on Twitter: the inspiration here was that the libsass compiler's import error, which lists the load paths it tried, didn't include any of the paths to Eyeglass modules. More / original tweets here: https://twitter.com/jkohlmann/status/649359893682606080

[eoneill]

eyeglass should output an error when it can't find a module / import path. This error will look something like...

Error: src/scss/main.scss
  1:9  Could not import foo from any of the following locations:
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo.scss
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo/index.scss
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo.sass
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo/index.sass
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo.css
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo/index.css
  /Users/eoneill/workspace/eyeglass-test/src/scss/_foo.scss
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo/_index.scss
  /Users/eoneill/workspace/eyeglass-test/src/scss/_foo.sass
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo/_index.sass
  /Users/eoneill/workspace/eyeglass-test/src/scss/_foo.css
  /Users/eoneill/workspace/eyeglass-test/src/scss/foo/_index.css
  ...

That said, the importer is somewhat fragile and has to know the file origin (path on disk) to correctly resolve the imports.

Depending on your build pipeline, this information isn't always made available to eyeglass and can cause useless and misguiding errors (like Undefined variable: "$foo" or no mixin named foo). See #64 #42 dlmanning/gulp-sass#353

There's also a bug in eyeglass' import-once logic that can cause this odd behavior and again results in a useless / misguiding error message. See #65

That said, I still like the idea of getting debugging information as this can be quite confusing at times :)

[chriseppstein]

I think I might have fixed the case where imports fail silently in my latest commit: 897b33e#diff-a1fa89b3186a6775a467efe40ba3c98aL180

[kohlmannj]

@chriseppstein The change in this commit definitely helps! Good deal. One headache-inducing problem:

I'm picking up Eyeglass a month later after shipping a major project, and now I can't even successfully import anything. For example:

>> Could not import ../su from susy/language/susy
>>   Line 6  Column 9  node_modules/susy/sass/susy/language/_susy.scss

So…relative imports within an Eyeglass module are now failing? I'm unsure, and I realize this thread is minorly digressing into a mini-support issue, but the fact is that I don't know how to troubleshoot this, and if I don't, I can't possibly, for example, help coworkers with other projects reliant on Eyeglass (sad face).

I should add: I know @eoneill mentioned some important caveats. I'll add that I'm using grunt-sass with node-sass 3.4.1 and libsass 3.3.1 as of this writing. I'd love to know how I might configure my environment to provide more importer error information.

[eoneill]

You can try using gulp-sass@1.0.0 (along with eyeglass@0.6.4), which will downgrade node-sass to 3.3.3.

This was a regression in node-sass as of 3.4.0. It will be fixed in 3.4.2, at which point you can use gulp-sass@1.1.0 again.

Apologies for the inconvenience. See also #69 for some more detail.

[kohlmannj]

@eoneill No apologies necessary; I know software dev is such a joy sometimes 😝 Unfortunately I'd have to move a bunch of stuff from Gulp to Grunt (and even if that's a good idea, I can't justify it right now), so I may have to wait it out here. Thanks though.

[eoneill]

Ah, yeah, I keep getting gulp-sass and grunt-sass mixed up with this node-sass issue :)

Unfortunately, I don't think there's a workaround for gulp-sass (due to the node-sass@^... dependency), unless you fork it.

[eoneill]

Actually, I take that back... With gulp-sass, you should be able to do the following.

In your project's package.json, lock the version of node-sass to 3.3.3:

"devDependencies": {
  "node-sass": "3.3.3"
}

Then in your gulp task, explicitly set that as the compiler for gulp-sass to use:

var nodeSass = require("node-sass");
var gulpSass = require("gulp-sass");

gulpSass.compiler = nodeSass;

...

[chriseppstein]

Fixed in 0.7.0