sass-eyeglass/ember-cli-eyeglass

Use eyeglass and node-sass to compile Sass files in your ember project.

ember-cli-eyeglass's Issues

importing an eyeglass addon into a non-eyeglass addon

I have an existing addon, @fastly/style-guide. I'm trying to extract eyeglass-aware pieces out of it. In this case, I'm trying to pull out @fastly/fui-color.

// @fastly/fui-color/index.scss
:root {
  --purple: rebeccapurple;
}

// @fastly/style-guide/app/styles/fastly/variables/_colors.scss
@import "@fastly/fui-color";

// @fastly/style-guide/tests/dummy/app/styles/app.scss
@import "fastly/variables/colors";
body { color: var(--purple); }

When I try to build this, it fails:

 - name: Error
  - nodeAnnotation: EyeglassCompiler
  - nodeName: EyeglassCompiler
  - originalErrorMessage: Error: Could not import ~@fastly/fui-color from any of the following locations:
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color.scss
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color.sass
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color.css
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/_fui-color.scss
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/_fui-color.sass
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/_fui-color.css
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/index.scss
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/index.sass
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/index.css
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/_index.scss
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/_index.sass
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/_index.css
    at /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/_all.scss:11:9
  - stack: Error: Error: Could not import ~@fastly/fui-color from any of the following locations:
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color.scss
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color.sass
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color.css
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/_fui-color.scss
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/_fui-color.sass
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/_fui-color.css
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/index.scss
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/index.sass
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/index.css
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/_index.scss
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/_index.sass
  /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/~@fastly/fui-color/_index.css
    at /Users/jamesrosen/Code/style-guide/tmp/eyeglass_compiler-input_base_path-CRY4bAvX.tmp/app/styles/fastly/variables/_all.scss:11:9
    at options.error (/Users/jamesrosen/Code/style-guide/node_modules/node-sass/lib/index.js:286:26)

Some hypotheses:

• @import with namespaced packages doesn't work
• there's something wrong with my ember-cli-build.js or another configuration file
• I haven't declared @fastly/fui-color as "eyeglass-aware" (though it doesn't contain any Sass JavaScript)
• ember-cli-eyeglass doesn't work in the dummy app of an addon

I'm using [email protected].

add windows CI

Rebuilds Don't Seem To Invalidate

Steps to repro:

1. git clone [email protected]:sass-eyeglass/ember-cli-eyeglass.git
2. cd ember-cli-eyeglass && yarn
3. ember s
4. Change color from yellow to blue in tests/dummy/lib/eager/addon/styles/addon.scss
5. Notice that styles do not update

I also confirmed that the templates do update and appears to only be the styles.

No error reporting?

I have been trying to set up ember-cli-eyeglass for my open source app Bookmeister, switching from Ruby Sass.

I guess it's not too surprising that it doesn't compile immediately without errors, but the problem I'm struggling with is that all errors seem to be squelched somewhere inside Broccoli.

So if I make a really simple app.scss file, like this:

body {
  background-color: chartreuse;
}

…everything works just fine. A bookmeister.css file is created with those contents.

The problem occurs when I try to use my previous setup, as before with partials and Sass libraries, ember build just stops generating a bookmeister.css file at all.

I have tried digging a bit into this library, and broccoli-eyeglass beneath it, but I have not been able to figure out which of the two causes the errors to be silenced, so I'm filing this here. I'll try to investigate further on my own, but if anyone had a few pointers on where I should look, I would be grateful.

(Lazy? Engine)? configuration doesn't set httpRoot from ember's rootURL config

There was an app that had to set httpRoot explicitly in the eyeglass config instead of it being inferred by the ember config.

Support .sass extension

I feel discriminated. :)

Support custom `httpRoot`

My assets are hosted on a separate server from my Ember application, so I need to customize the httpRoot option, which defaults to my Ember application's URL.

// config/environment.js
module.exports = function(environment) {
  var ENV = {
    eyeglass: {
      // It would be nice if I could set the `httpRoot` like this:
      httpRoot: 'https://cdn.com/',

      // I've gotten it to work using the `optionsGenerator` like this, 
      // but seems a bit messy.
      optionsGenerator(sassFile, cssFile, options, callback) {
        options.httpRoot = 'https://cdn.com/';
        callback(cssFile, options);
      }
    }
  };
};

I'd be happy to work on a PR, but I'm confused when/where the httpRoot is actually being set.

Addon Styles Are Not Built

addon/styles/<addon_name>.scss doesn't get included in the build. To parallel default ember-cli functionality, which includes addon/styles/<addon_name>.css in the build, it should.

This is probably related to #9.

cc @chriseppstein @stefanpenner

cssDir : Not passed through

The cssDir option is not passed through to broccoli-eyeglass. I think this should be documented on the main page as it's not immediately obvious.

Asset Handling Overhaul

There's a number of issues involving assets and how they work in eyeglass with ember apps, especially with ember engines, and especially when those engines are in lazy mode. We're going to change the way assets are configured by default for ember applications so that asset-url() works better and more predictably for ember applications.

Constraints

Current invocations of asset-url() will continue to work unmodified, providing backwards compatibility to existing apps. This change must be non-breaking and introduce no deprecations. The only risk for apps is if there is a url to an asset installed by eyeglass during compilation, where that URL has been hard-coded instead of referencing the asset according to the url returned by asset-url() or asset-uri().

Current Problems:

• In some cases, assets installed by eyeglass do not end up in the final build.
• Assets in an addon are installed by eyeglass as well as by ember-cli, and depending on configuration, they might be duplicated and have different urls, resulting in additional asset transfer for some applications.
• Transitive dependencies on assets delivered by the same eyeglass module in an application can result in the same asset being installed in different locations on a per consuming engine, addon, or application basis.
• It's unclear whether relative asset paths are working correctly across the range of use cases for builds occurring in addons and engines.
• It's unclear whether assets can be correctly referenced from both the addon and app directories using asset-url().
• It's unclear whether assets are correctly handled for nested engines/addons.

Design

Assets delivered from an eyeglass module should be installed to a canonical location. Because eyeglass modules are guaranteed to resolve to a single instance, the assets are guaranteed to be the same across multiple transitive dependencies even if they resolve from npm to different versions.

Asset Installation and Default URLs

Assets will be installed according to the source location.

• Assets in the public directory of an application or addon can be referenced by the asset-url() function. Baring intervention from a custom installer, Eyeglass will not install these assets, but it will return a url that conforms to the location that ember will ultimately install the public asset.
• Baring intervention from a custom installer, Assets from an eyeglass module will be installed into assets/eyeglass-modules/<module-name>/<path-to-asset>. ember-cli-eyeglass will accept a new configuration parameter that allows the directory of eyeglass module assets to be specified but it will default to assets/eyeglass-modules. The behavior of how conflicts between installed assets and assets in the public directory is handled will be documented, but it is decided by whatever ember-cli does naturally.
• An ember engine that is also an eyeglass module can expose assets from a non-public directory. (Open Question: Should addons have this ability without becoming an eyeglass module? The answer may depend on how overrides turn out to work.)

Asset Overrides:

Note: there is currently an override behavior in eyeglass, but it's really not clear how it interacts with ember-cli's public directory semantics We need to decide what the right semantics are and make sure it's clearly documented and implemented accordingly.

Here's how I think it should work:

Assets in the public directory of the app can override the asset normally delivered by an engine, addon, or module by having an asset in a directory that overrides that of the same source url. For example, if an engine or addon named my-swanky-addon has an asset at <addon-root>/public/assets/icons/swanky.gif, then that can be accessed via asset-url("my-swanky-addon/icons/swanky.gif"). If the app puts a different image in the public directory at <app-root>/public/assets/my-swanky-addon/icons/swanky.gif, this will be the asset resolved regardless of whether the app or addon is the one creating the url.

If the asset is referenced as asset-url("icons/swanky.gif") from either the addon or the app, it will still work, but the override location will then be <app-root>/public/assets/icons/swanky.gif and I need to know whether this file would be overwritten by the addon or if the app wins according to ember-cli semantics.

I think the decisions for how to find files in the public directory are based on a merged app tree, not the application source. This means that addons can deliver assets to the app's public directory that have the effect of overriding the assets of other eyeglass addons or modules. This allows for overriding of assets by an addon that nests another addon or is installed along side the main application.

Asset overriding must work the same for both lazy and eager engines, even though lazy engines have a different broccoli tree.

WIP

There's still some unanswered aspects but I want to make sure this core design is solid.

Changes to Lazy Css Not Picked Up

After making changes to dummy/lib/lazy/addon/styles/addon.scss and running npm run build, changes are not reflected in dist/engines-dist/lazy/assets/engine.css. Only after rm -rf node_modules, yarn, npm run build are changes reflected in dist/engines-dist/lazy/assets/engine.css.

Steps to repro:

1. git clone [email protected]:sass-eyeglass/ember-cli-eyeglass.git
2. cd ember-cli-eyeglass
3. yarn
4. npm run build
5. cat dist/engines-dist/lazy/assets/engine.css
6. Make a change to dummy/lib/lazy/addon/styles/addon.scss
7. npm run build
8. cat dist/engines-dist/lazy/assets/engine.css
9. Observe that changes are not picked up

acceptance tests need to actually test things

Ember Build problems

I was using ember-cli-sass and this works well however I'm interested in using Eyeglass.

I removed ember-cli-sass and installed ember-cli-eyeglass

When I attempt to build with ember-cli-eyeglass I get the following error:
Build failed.
The Broccoli Plugin: [EyeglassCompiler: EyeglassCompiler: leftoverbits] failed with:
Error: File to read not found or unreadable: Z:/EmberJS/myproj/tmp/eyeglass_compiler-input_base_path-W0yfYjmr.tmp/Z:/EmberJS/myproj
/tmp/eyeglass_compiler-input_base_path-W0yfYjmr.tmp/app/styles/app.scss
at undefined:undefined:undefined

I'm running on Windows 10 x64.

Load app/addon config from ember-cli-build.js/index.js and deprecate loading from environment.js

Problem:

We currently load configuration for the app/addon/engine we're building styles for from its environment.js file. Config values defined in that file our sent to the browser at runtime, so it'd be better if we instead have consumers define them in a place that isn't sent to the browser, since there's no need to have Eyeglass config values available at runtime.

Proposed Solution:

We should start looking for eyeglass configs on the config values coming from an app's ember-cli-build.js and an addon/engine's index.js. Values from these sources are only used at build-time and aren't sent to the browser. When a consumer defines both, we should prefer the build-time only config and warn them that it is being used instead of the one from environment.js. When a consumer defines eyeglass configs in environment.js, we should warn them that it is deprecated and they should move the configs to the build-time sources.

Details:

For an app, consumers can place an eyeglass key on the options passed to new EmberApp(). We should update our README to reflect this as the appropriate place for app configs.

For an addon/engine, consumers can place an eyeglass key on this.options in the init() method defined in the addon/engine's index.js. For an example, see this from ember-computed-decorators: https://github.com/rwjblue/ember-computed-decorators/#setup-with-addon
We should update our README to reflect this as the appropriate place for addon/engine configs.

In ember-cli-eyeglass, we can then access the config using this.parent.options or this.app.options. Here's an example of how ember-cli-babel does this: https://github.com/babel/ember-cli-babel/blob/master/index.js#L95-L97

Credits:

Thanks to @rwjblue for guiding me through the possible solution and for being a point-of-contact for Ember CLI-related details.

Readme fixes

// path/to/app/ember-cli-build.js
const app = new EmberApp(defaults, {
  options: {
    eyeglass: { /* configuration */ }
  }
});

should be:

// path/to/app/ember-cli-build.js
const app = new EmberApp(defaults, {
   eyeglass: { /* configuration */ }
});

enable travis

i can add the .travisyml stuff, but I can't enable travis. Likely a good idea to get CI on this.

Eyeglass in Ember addons and engines

When including ember-cli-eyeglass for sass compiling within an addon or engine, Eyeglass only looks inside the app directory, not the addon directory (app should be empty), and complains. Root issue is really with eyeglass not able to compile an addon, since it only looks in node_modules/ember-cli-eyeglass/index.js, looks for consuming app's env, and then dies:

Example error output:

⠋ BuildingCannot read property 'env' of undefined
TypeError: Cannot read property 'env' of undefined
    at Object.registry.add.toTree (/Users/cklimkow/workspace/testmanager-engine_trunk/node_modules/ember-cli-eyeglass/index.js:34:59)

Current hack/work-around:

//package.json
"eyeglass": {
    "exports": "eyeglass-exports.js",
    "name": "addon-name",
    "needs": "^0.8.2"
  },
  "keywords": [
    "ember-addon",
    "eyeglass-module"
  ]

...and then we create an eyeglass-exports.js file in the root:

//eyeglass-exports.js
/* jshint node:true */
var path = require('path');

module.exports = function(/* eyeglass, sass */) {
  return {
    sassDir: path.join(__dirname, 'addon', 'styles')
  };
};

Consuming Ember app must then @import "addon-name"; in its app.scss.

/cc @cklimkowsky @nathanhammond

Config is currently in the client-side config

rather it should be in the build config. Otherwise we ship our configuration to the browser, which is wasteful.

broccoli builds fail in v 1.0.1

Hi there,

Just tried to update to ember-cli-eyeglass 1.0.1, and broccoli builds now fail starting at Object.registry.add.toTree in node_modules/ember-cli-eyeglass/index.js with a TypeError ("undefined is not a function.")

I can provide the full stacktrace if you need it.