This is a general planning issue for simplifying our API for the 1.0 release. I'll make new issues for things that we decide here.

sassDir

Currently, we allow sassDir to be specified in package.json as well as in eyeglass-exports.js.

The package.json approach is much more user friendly. However, the eyeglass-exports.js approach
allows the module to inspect the eyeglass options before deciding on the Sass directory. There is
some interesting things this enables, like letting people opt into a new version of a module's
stylesheets by setting some option. But this is unlikely to be useful very often and there's
probably a simpler way to accomplish that use case.

eyeglass-exports.js location

Currently you can specify the eyeglass-exports file three ways in package.json:
pkg.main, pkg.eyeglass, and pkg.eyeglass.exports. Given that we basically require a
pkg.eyeglass.needs attribute at the very least, the pkg.eyeglass seems useless.

I think the pkg.main form has some usefulness for pure eyeglass modules.

revisit require('eyeglass') exports

This currently exports a class and a decorator function.

// class function
var Eyeglass = require('eyeglass').Eyeglass;
// decorator function
var eyeglass = require('eyeglass').decorate;

We can collapse this into
a single function that behaves differently depending on whether it is called with new.

// returns an eyeglass instance
var Eyeglass = require('eyeglass');
var eyeglass = new Eyeglass({});
// returns options
var eyeglass = require('eyeglass');
var sassOptions = eyeglass({});

I'm not sure I'm a fan of this approach. Alternatively we can leave decorate as a function
attached to the exported function.

// returns an eyeglass instance
var Eyeglass = require('eyeglass');
var eyeglass = new Eyeglass({});
// returns options
var sassOptions = Eyeglass.decorate({});

What else?

If there are other redundant configuration or APIs, please mention them.

Is bundling custom C function out of the scope for eyeglass?

Pretty self explanatory. Being able to distribute, install and register custom Libsass C functions would be great. It would certainly ease the distribution of custom behaviour without requiring the forking of Libsass (this is a decision I'm currently facing in my team).

We've got a bower-managed package named zd-css-settings.weights containing a SCSS file we want to import.

The line is:
@import '../../../bower_components/zd-css-settings.weights/settings.weights';

and it blows up thusly:

module.js:340
    throw err;
    ^
Error: Cannot find module 'zd-css-settings.weights/package.json'
    at Function.Module._resolveFilename (module.js:338:15)
    at resolve (/harmony/code/zendesk_console/node_modules/broccoli-eyeglass/node_modules/eyeglass/lib/util/resolve.js:19:17)
    at /harmony/code/zendesk_console/node_modules/broccoli-eyeglass/node_modules/eyeglass/lib/util/discover.js:151:17
    at Array.forEach (native)
    at discover (/harmony/code/zendesk_console/node_modules/broccoli-eyeglass/node_modules/eyeglass/lib/util/discover.js:150:25)
    at Object.getModules [as all] (/harmony/code/zendesk_console/node_modules/broccoli-eyeglass/node_modules/eyeglass/lib/util/discover.js:198:19)
    at Object.ImportUtilities.getModuleByName (/harmony/code/zendesk_console/node_modules/broccoli-eyeglass/node_modules/eyeglass/lib/import_utils.js:38:29)
    at Object.<anonymous> (/harmony/code/zendesk_console/node_modules/broccoli-eyeglass/node_modules/eyeglass/lib/module_importer.js:66:30)
    at options.importer (/harmony/code/zendesk_console/node_modules/node-sass/lib/index.js:321:31)

https://docs.npmjs.com/misc/scope

We're using the @linkedin module scope here at work and things are not auto-discovered correctly.

need to test for the presence of the done() function.

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

See #82.

However, we should resolve relative entries in the SASS_PATH against the current working directory as that is the UNIX approach. https://github.com/sass-eyeglass/eyeglass/blob/master/lib/index.js#L45

It might be useful to document somewhere in the README how to use eyeglass with grunt-sass, as it wasn't immediately clear to me.

I've got it working like this:

sass: {
    options: require("eyeglass")({
        sourceMap: true
    }).sassOptions(),
    dist: {
        files: {
            'public/css/main.css': 'sass/main.scss'
        }
    }
}

Greetings,

is there any plans on adding a configuration file feature ?

Something like an .eyeglassrc that would only be found at a project root, and would allow to share configuration keys between modules.

Alternatively it could make use of package.json but I tend to lean towards a separate file.

The js-yaml package can bring both JSON and YAML support out of the box.

One (of the many) great features of Compass is its config.rb file. So that project wide configuration (paths, dirs, urls, cache, ...) can be set in one place and shared between libraries.

Hi Chris, thanks for your work so far on eyeglass.

I was wondering about the reason for using sass as the name of the folder in that get's added to node-sass's load path? To me it would make more sense to follow the convention that compass uses - which is to use the stylesheets folder (why am I linking you to this page, you wrote the dang thing...).

This would allow existing compass extensions that are pure Sass (and compile in both Ruby Sass and libsass) to be referencable through eyeglass without needing to create duplicate files within their repositories.

For a bit of context, I maintain Breakup, a Sass utility which is packaged as a Compass extension for convenience of developer consumption through RubyGems. As it is essentially a single Sass file that uses long-supported features it is also compatible with libsass, so I have also packaged it and placed in on npm. If eyeglass used the stylesheets folder then Breakup would "just work":tm: and people could @import "<breakup-sass>/breakup";. However as eyeglass currently uses the sass folder I would need to create a duplicate of stylesheets/_breakup.scss in the sass folder and keep these two files in sync.

Would you consider changing from sass to stylesheets to help consistency and save on this potential for duplication?

What if the eyeglass module "test" uses a different version of eyeglass module "math-eyeglass"
as dependency than, let's say, eyeglass module "modular-scale"?

The version of the module package is specified in package.json of the respective @importing eyeglass modules package, and they can be well different.

Will an @import yield different SCSS/SASS styles, eyeglass assets and functions
for each @importing module, isolated from the other eyeglass modules that may use a different version of it?

Or is one version picked for globally for all @importing eyeglass modules,
regardless of the dependency version in their package.json?

To test on Node.js 4.travis.yml will need:

node_js:
  - '0.12'
  - '4'

Hi,

Now that Eyeglass gets called through decorate(), is there a way for eyeglass to grab assets? Perhaps by adding the sources to node-sass options?

does indentedSyntax is supported by Eyeglass?

sass.js

var gulp         = require('gulp');
var sass         = require('gulp-sass');
var handleErrors = require('../lib/handleErrors');
var config       = require('../config/sass');
var debug        = require('gulp-debug');
var Eyeglass     = require("eyeglass");

var config = {
  autoprefixer: { browsers: ['last 2 version'] },
  src: [
    config.sourceAssets + "/stylesheets/**/*.{sass,scss}",
   ],
  dest: config.publicAssets + '/stylesheets',
  settings: {
    indentedSyntax: true, // Enable .sass syntax!
    imagePath: 'assets/images' // Used by the image-url helper
  }
}

var eyeglass = new Eyeglass(config.settings);
//console.log(config.settings)
//console.log(eyeglass.sassOptions())

gulp.task('sass', function () {
  return gulp.src(config.src)
    .pipe(sass(eyeglass.sassOptions())) 
    .on('error', handleErrors)
    .pipe(gulp.dest(config.dest))
});

app.sass

.myApp
  background: green

exception fired: invalid top-level expression

As separate issue from #42 (comment)

I try to use this custom importer with eyeglass: https://github.com/at-import/node-sass-import-once

[...]
  var eyeglass = new Eyeglass({
    importer: importOnce,
    importOnce: {
      index: true,
      css:   false,
      bower: false
    }
  });
[...]

However, the importer isn't able to see the importOnce property in options object,
is there a way to pass it to the custom importer when eyeglass is used instead of plain node-sass?

/home/build/src/test/node_modules/node-sass-import-once/index.js:275
  if (!this.options.importOnce) {
                   ^

TypeError: Cannot read property 'importOnce' of undefined
    at Object.importer [as fallbackImporter] (/home/build/src/test/node_modules/node-sass-import-once/index.js:275:20)
[...]

When using eyeglass via Grunt and configuring it as explained in the example, the includePaths don't seem to work. I'm using [email protected] and [email protected], currently configured as:

...
var neat = require('node-neat').includePaths;
var paths = ['./sass/'].concat(neat); // this will also add bourbon

grunt.initConfig({
    ...
    sass: {
      options: require("eyeglass")({
        includePaths: paths,
        sourceMap: true,
        outputStyle: 'compressed'
      }).sassOptions(),
      files: {
        '<%= clientCssOutputPath %>main.css': '<%= clientSassPath %>main-extend.scss',
        '<%= clientCssOutputPath %>ie.css': '<%= clientSassPath %>ie-extend.scss',
      }
});
...

I left out some variables and code, but all folders are correct. Getting the following error:

Could not import main from any of the following locations: ...

The locations it looks in never include the includePath folders. This works if I don't initialise eyeglass via:

...
options: {
    includePaths: paths,
    sourceMap: true,
    outputStyle: 'compressed'
},
...

One of compass's inordinately handy features was the ability to set background position values on sprites as percentages, not as pixels. I used the heck out of that in multiple projects, including: http://rachelnabors.com/blackbrickroad/

See also: sass/node-sass#651

We need to give better errors when imports from node modules fail.

Following up from this comment: #22 (comment)

/cc @ericam @aaronagray

When a node module should require itself from within its module directory (notably for testing),
one usually requires it using a relative path:

var module = require('../');

Is this the same for testing a module from itself?
I tried @import 'file-text'; or @import '../'; but it doesn't work:

Uncaught AssertionError: Could not import file-text from stdin

or

Uncaught AssertionError: Could not import ../ from stdin

You can test this by:

git clone https://github.com/strarsis/eyeglass-file-text.git
git checkout v0.1.0
nvm use v4.0.0 # for example
npm install
npm test

Some other tests may also fail at this time,
but the @import which is the requirement for testing is failing:

Uncaught AssertionError: Could not (import file-text or ../) from stdin

It appears that most plugins architected on top of node-sass use the options object directly. Because eyeglass wants to wrap the options once per render call, this leaves eyeglass incompatible with many node-sass plugins. Instead of changing all of the plugins, this is a proposal to instead wrap node-sass using cowboy/javascript-hooker or a similar library.

Passing options through

I discovered this issue while exploring what changes we would need to make in dlmanning/gulp-sass in order to support eyeglass. Instead of just an object literal, a function would need to be passed to gulp-sass which returns an options object. This way, during the map stream transform, a new option object would be generated each time, ensuring that eyeglass decoration works as expected.

Researching additional node-sass plugins for build systems such as sindresorhus/grunt-sass and joliss/broccoli-sass, these too would need to be updated if anything other an an Object literal was going to be passed in to the plugin.

It's my opinion that it is unreasonable to ask every node-sass plugin for a build system to support config decoration.

Alternatives

• making a X-eyeglass which in turn piped through X-sass: This thin layer of option passing would need to step in during the stream read / per file. We would need to create these per build system. Unfortunately, some build systems such as gulp use object streams which means stitching streams in the plugin which adds to the total amount of maintained code.
• utilize gulp-tap as a recipe: Specifically a solution for gulp geejs/gulp-tap would allow people to use node-sass directly in their projects. However, all of the sourcemap support falls apart, a major feature in gulp-sass.
• update node-sass to support a function for generating options: The cascade effect of this would be plugin authors updating in order to support this feature universally. However, adding this support be a somewhat significant feature add. I'd like to only ask for this as a last resort.

Proposal

Ideally, I'd like eyeglass to work with these sass plugins naturally without any modification to their code, or having to create & maintain separate X-eyeglass plugins for build systems. Because the options object is passed through directly to node-sass, we should consider addressing instead modifying the .render() and .renderSync() methods in node-sass.

cowboy/javascript-hooker or a similar library will allow us to cleanly proxy the render / renderSync methods, invoking eyeglass once per call. Monkey Patch libraries also come with an API for unhooking, should a developer need to run node-sass without the eyeglass functionality.

This changes our invocation signature from

nodeSass.render(eyeglass({
  /* options */
}));

to

require("eyeglass")(nodeSass); // require("eyeglass").bind(nodeSass);
nodeSass.render({
  /* options */
});

require("eyeglass").unbind(nodeSass);

I'd really love to collect more thoughts on this, the idea of monkey patching in node.js (completely supported but often only used in testing), and the implications of doing an interface like this.

A thrown error from an exported js function is translated into a sass error - halting the compilation.
Is there also a means to throw a warning (like @warn in native sass) from an exported js function?

I use the gulp code from docs/integrations/gulp.md.
The top level (non imported) files are parsed and compiled to output css
but the @imported files are ignored/skipped.

sass.compiler.types.NULL is undefined,
but also when using sass.compiler.types.Null instead won't solve this issue.

Passing true, makes it possible to @import normally - but not the eyeglass modules:

done(true);

Using node 0.12.7, gulp 3.9.0, eyeglass 0.6.2, gulp-sass 2.0.4 and node-sass 3.2.0.

error in C function eyeglass-asset-uri: Asset not found: icons/icon_gear.svg

Backtrace:
    eyeglass/assets:53, in function `eyeglass-asset-uri`
    eyeglass/assets:53, in function `asset-url`
    activities/discovery/stylesheets/discovery.css.scss:273
Build failed.
error in C function eyeglass-asset-uri: Asset not found: icons/icon_gear.svg

Backtrace:
    eyeglass/assets:53, in function `eyeglass-asset-uri`
    eyeglass/assets:53, in function `asset-url`
    activities/discovery/stylesheets/discovery.css.scss:273
    at eyeglass/assets:53:15

Okay. So where did eyeglass look?

Correctly (the Sass way), custom functions return a sass.types.Error object when they encounter errors. However, that is not very node-like. Instead, we should probably be proxying the function, use wait.for, and make the callbacks in eyeglass behave as if they are truly node async functions. This means:

1. Automatically provide a done() callback if one doesn't exist
2. Intelligently use wait.for to block async resolution in renderSync mode (no done callback incoming)
3. Provide an alternate node-friendly done() to the custom function that will take any error object from done(error, null) and properly class it into a sass.types.Error object.

Does it make sense to try to support other package managers in eyeglass like bower?

True fact: CSS files are scss files. So we can import them as long as people don't put the extension in the import (that triggers sass to treat it as a css import).

Me and others can't get custom functions declared in eyeglass-exports.js to work in the context of .scss:

sass-eyeglass/eyeglass-sample#1

cc @ahmedelgabri

In this commit, a reference to the Eyeglass object is made inside the options object 9479bbf#diff-6d186b954a58d5bb740f73d84fe39073R31

Because the options object is also assigned to the eyeglass object, this creates a circular reference. So if you want to walk the options object, you would get an infinite recursion in the form of eyeglass.options.eyeglass.options.eyeglass.options.eyeglass.options etc.

Grunt, being the busybody it is, wants to walk the options, resulting in this error message:

Fatal error: Circular reference detected (.eyeglass.options)

If nothing else, the circular reference should be removed when calling .sassOptions().

We need to figure out how assets (images, fonts, etc) will get out of npm modules and into a location that is servable for the application.

Currently, my idea is to provide a helper function like eyeglassAssets(destinationDir) that would return a map of source files to the desired destination directory. This could then be easily integrated into various build pipelines so that the files are never placed into the application's assets locations like they are with compass.

When following Grunt integration I am getting this error reported:

Fatal error: Arguments to path.resolve must be strings

Steps to reproduce:

Add the following to your package.json

{
  "devDependencies": {
    "eyeglass": "0.6.3",
    "grunt": "0.4.5",
    "grunt-sass": "1.1.0"
  }
}

Create a file named Gruntfile.js that contains this:

'use strict';

var eyeglass = require("eyeglass");

module.exports = function(grunt) {
    grunt.initConfig({
        watch: {
            sass: {
                files: ['*.{scss,sass}', 'Gruntfile.js'],
                tasks: ['sass:dist']
            },
        },
    sass: {
      options: require("eyeglass").decorate({
        sourceMap: true
      }),
      dist: {
        files: {
          'style.css': 'style.scss'
        }
      }
    }
    });
    grunt.registerTask('default', ['sass:dist']);
    grunt.loadNpmTasks('grunt-sass');
};

Create a file named style.scss with the following:

.title {
    content: 'Eyeglass is Awesome!';
}

Than run:

grunt

ES6 is pretty nice. Any objections to using it for development of eyeglass modules and transpiling it down?

It is a known bug, import-once doesn't play well with Gulp.

I've opened this issue to track the resolution of the problem.

Based off of @chriseppstein's presentation at the Sass unconference, write a guide for people who just want to get eyeglass up and running.

(sassDir specified in package.json)

With SVG, you can refer to a specific part of it using an id, which ends up looking like url(icons.svg#octogon).

However, this confuses Eyeglass and it says it can't find an asset named icons.svg#octogon

I will work around this by concat-ing the fragment onto the returned URL from asset-file(), but wanted to surface this issue.

This is a bit of a major change, but I believe that incorporating Eyeglass modules into a project will have less friction by simply exporting a factory function instead of a raw Eyeglass object.

OLD API:

var sass = require('node-sass');
var Eyeglass = require('eyeglass');
var sassOptions = { ... };
var eyeglass = new Eyeglass(sassOptions); // boilerplate

eyeglass.assets("assets/images", "images", "public/images"); // imperative

// eyeglass.sassOptions() is also boilerplate
sass.render(eyeglass.sassOptions(), function(err, result) { ... });

NEW (proposed) API:

var sass = require('node-sass');
var eyeglass = require('eyeglass');
var sassOptions = { ... };
var assets = [
  {source: 'assets/images', http: 'images', build: 'public/images'} 
]; // declarative and clear

sass.render(eyeglass(sassOptions, { assets: assets }), function(err, result) { ... });

So the arguments would simply be eyeglass(sassOptions, eyeglassOptions) and would return a POJO equivalent to Eyeglass.prototype.options. Both bits of boilerplate are eliminated, and it also allows the developer to do this shorthand:

var sassOptions = { ... };
var eyeglassOptions = require('eyeglass')(sassOptions);

What do you think? I believe it's more intuitive and idiomatic.

The eyeglass-inline-svg module @imports the eyeglass-file-text module.
Now I get a Segmentation fault when @importing.
It seems that functions from eyeglass-exports.js are auto-imported/loaded without using @import,
but not sass from sass/ directory of the module.
Is the Segmentation fault caused by recursive importing because of the behaviour described above?

What approach is the right one?
@import another eyeglass module when it is used in any way?
@import only for the sass files, not for exported functions?

I prepared a sample repository for this: https://github.com/strarsis/eyeglass_import_test

$ git clone https://github.com/strarsis/eyeglass_import_test.git
$ cd eyeglass_import_test
$ nvm use v4.0.0 # (for example)
$ npm install
$ npm install -g gulp-cli (if not already installed)
$ gulp

[16:30:50] Using gulpfile ~/eyeglass_import_test/Gulpfile.js
[16:30:50] Starting 'svg'...
[16:30:50] Finished 'svg' after 137 ms
[16:30:50] Starting 'sass'...
[16:30:50] Finished 'sass' after 17 ms
[16:30:50] Starting 'default'...
[16:30:50] Finished 'default' after 13 μs
Segmentation fault

This used to work, and works with standard Sass.

In my Sass files, I have a @import "toolkit/kickstart"; statement, which is supposed to load the file from node_modules/sass-toolkit/stylesheets/toolkit/_kickstart.scss.

But Eyeglass seems to strip out the toolkit/ part when searching for the file, as you can see in the error message:

Error: Could not import toolkit/kickstart from any of the following locations: /Users/mikl/Work/Liip/Freitag/vkosf6x3zlyoi/repository/themes/neocortex/sass/partials/global/toolkit/kickstart.scss
sass/partials/global/toolkit/kickstart/index.scss
sass/partials/global/toolkit/kickstart.sass
sass/partials/global/toolkit/kickstart/index.sass
sass/partials/global/toolkit/kickstart.css
sass/partials/global/toolkit/kickstart/index.css
sass/partials/global/toolkit/_kickstart.scss
sass/partials/global/toolkit/kickstart/_index.scss
sass/partials/global/toolkit/_kickstart.sass
sass/partials/global/toolkit/kickstart/_index.sass
sass/partials/global/toolkit/_kickstart.css
sass/partials/global/toolkit/kickstart/_index.css
node_modules/sass-toolkit/stylesheets/kickstart/index.scss
node_modules/sass-toolkit/stylesheets/kickstart.scss
node_modules/sass-toolkit/stylesheets/kickstart/index.sass
node_modules/sass-toolkit/stylesheets/kickstart.sass
node_modules/sass-toolkit/stylesheets/kickstart/index.css
node_modules/sass-toolkit/stylesheets/kickstart.css
node_modules/sass-toolkit/stylesheets/kickstart/_index.scss
node_modules/sass-toolkit/stylesheets/_kickstart.scss
node_modules/sass-toolkit/stylesheets/kickstart/_index.sass
node_modules/sass-toolkit/stylesheets/_kickstart.sass
node_modules/sass-toolkit/stylesheets/kickstart/_index.css
node_modules/sass-toolkit/stylesheets/_kickstart.css

If Eyeglass had kept the toolkit/ part from the import statement, this would work fine.

At the moment it looks like eyeglass won't work without a build task using tools such as Broccoli.

Is there a way eyeglass could compile files directly in the terminal with its own CLI?

Hi,
I've an issue on _import-once_.

I have two different scss files that will be compiled in two different css files.
In both of these .scss files (for example: bootstrap.scss and application.scss) I need to import a single file called: _variables.scss.

The import-once module seems to prevent this behaviour and in the second file that requires _variables.scss I obtain

undefined variable: $variableName

is there any workaround for doing this?

Gius

During compilation, when importing a file, not sure where or which one yet, I get this error with latest eyeglass, downgraded node-sass (withtout the recursive import bug) and node v4.0.0:

path.js:8
    throw new TypeError('Path must be a string. Received ' +
    ^

TypeError: Path must be a string. Received undefined
    at assertPath (path.js:8:11)
    at Object.posix.join (path.js:477:5)
    at getPackage (/home/build/src/app/node_modules/eyeglass/lib/util/discover.js:10:20)
    at discover (/home/build/src/app/node_modules/eyeglass/lib/util/discover.js:96:22)
    at Object.getModules [as all] (/home/build/src/app/node_modules/eyeglass/lib/util/discover.js:198:19)
    at Object.ImportUtilities.getModuleByName (/home/build/src/app/node_modules/eyeglass/lib/import_utils.js:38:29)
    at Object.<anonymous> (/home/build/src/app/node_modules/eyeglass/lib/module_importer.js:66:30)
    at options.importer (/home/build/src/app/node_modules/node-sass/lib/index.js:321:31)

A lot of existing sass packages are already npm modules for one reason or another and they might have their own main script that does something completely different from the standard.

Specifically, I'm trying to support making true an eyeglass module.

A few options I see:

1. Try to require("my_npm_module/eyeglass-exports") and fall back to require("my_npm_module") if that doesn't work.
2. Always require("my_npm_module") but first check for require("my_npm_module").eyeglass so that if the can return an eyeglass function attached to some other object.
3. Don't support this... they would need to make a new npm module that wraps their other one and conforms to our existing api.

Ruby has gems, Eyeglass should have lenses. I don't want to install an eyeglass, I want to install a lens.

I installed eyeglass-math with npm and now try to @import it.
However, it seems to be stuck in a recursive loop

• but absolute paths are used as downgrade to node-sass v.3.3.3 is forced.

I prepared another git repo to quickly reproduce this issue:

git clone https://github.com/strarsis/eyeglass_import_test2.git
cd eyeglass_import_test2

nvm use v4.0.0
npm install

# force using node-sass v3.3.3:
rm -f ./node_modules/gulp-sass/node_modules/.bin/node-sass
rm -f ./node_modules/gulp-sass/node_modules/node-sass/bin/node-sass

gulp sass

(Hangs until terminated with Ctrl+c)

I use mostly the Gulpfile from eyeglass documentation (https://github.com/sass-eyeglass/eyeglass/blob/master/docs/integrations/gulp.md)
plus an importer function which doesn't help though.

Is this an issue with eyeglass-math or eyeglass or with the usage of it (Gulpfile / sass styles)?

node-sass v3.4.0 was just released. Our test suite currently has several failures against the new version.

I can't make eyeglass work, maybe it's something related to recent libsass/node-sass updates. My setup involve gulp and sass files but I tried to convert the files to scss too without success.

For reference my gulpfile contains something like this:

var eyeglass = new Eyeglass(sassOptions, sass.compiler);
eyeglass.assets("assets/images", "images", "public/images");
eyeglass.assets("assets/fonts", "fonts", "public/fonts");

gulp.src('src/*.sass')
  //.pipe(sass(eyeglass.sassOptions()))
  .pipe(sass(sassOptions))
  .pipe(gulp.dest('dist'));

If a sass file contains something like this:

@import "modules/my_module"
body
  background: red

The result looks like this:

body{background: red;}

In fact the problem exist as soon as I create a new instance of Eyeglass.

Look at various options and figure what will work best.

Needs:

• Ability to publish new version along with documentation simultaneously. Website code will live in this repository.
• Ability to use eyeglass in the build (use own dog food)

Options:

• http://assemble.io/
• http://harpjs.com/ (they've offered to allow a PR to include eyeglass as a default)