includePaths not working about ember-cli-sass HOT 16 CLOSED

You want to use @import 'normalize-scss/normalize';​
​

from ember-cli-sass.

I believe you might have misunderstood @ahacking's comment. Using the import statement you advocate, e.g.

@import 'normalize-scss/normalize';​

which you would expect to work having specified bower_components as an includePath, does not work ... you have to preface the import statement with bower_components despite having specified it as an includePath, as follows:

@import 'bower_components/normalize-scss/normalize';​

from ember-cli-sass.

@artzte thanks for clarifying, that was exactly my point, the include path should allow me to import without needing to preface the import with 'bower_components/'

from ember-cli-sass.

Yup - I have found the includePaths issue hugely confusing with broccoli-sass, i.e. I have no idea how to add import search paths for SASS.

from ember-cli-sass.

Hmmn, that is strange. That's not the behaviour that I'm seeing. Can you share your code so that I can have a look?

Each of trees that are passed to broccoli-sass are merged together, so bower_components/ shouldn't be a folder in the merged tree, unless you've got a bower_components/bower_components/ folder.

from ember-cli-sass.

I'm not using ember-cli anymore as its too buggy and slow and murdered my teams productivity. Sad but true.

Perhaps you can look at your own code and check if you pass the correct options to the sass tooling?

from ember-cli-sass.

@aexmachina Just reading your comment again sounds like it can never work, you say 'bower_components' will never be in the merged tree, so how then can an includePaths option EVER work?

from ember-cli-sass.

I have, and it's definitely correct. What it's doing is really very simple and is working for me. Sorry it wasn't useful for you. I'll close the issue just reopen it if you need to.

Re. bower_components/ - the contents of the folder is merged into the input tree.

from ember-cli-sass.

Closed because you cant be bothered?

Really this is unbelievable. I did an out of the box ember new and added normalize to bower.json, ran bower install and ember build and it fails to locate.

Not only do I have the issue but someone else as well.

from ember-cli-sass.

So if you merge the contents into the input tree how do you avoid collisions without preserving the prefix?

What options do you pass to libsass ? What paths is it getting ? Can I guess you are passing includePaths through for directories that no longer exist in the merged tree?

from ember-cli-sass.

@ahacking, let me just clarify something for you. You're using an open source module, and I don't have any responsibility to fix your problem for you. I've offered to take a look and you declined to provide me with an example, so I've closed the issue. Furthermore, being open source code, you have the source code so I invite you to take a look at it - you'll see that there's not much of it. I don't appreciate your attitude.

Now, moving along. You've provided me with an example, so now I'll take a look.

Regarding your questions, we don't do anything to avoid collisions. This is by design. The interface with libsass is handled by broccoli-sass, which passes the paths for its input trees to libsass. Your guess is incorrect.

from ember-cli-sass.

Furthermore, @ahacking, as expected I've just spent my own time to create a new ember app and confirmed that it is indeed working as expected:

ember new test-app
npm install --save-dev ember-cli-sass
bower install --save normalize-scss
mv app/styles/app.css mv app/styles/app.scss
# edit Brocfile.js
# edit app.scss
ember serve

Brocfile.js

/* global require, module */

var EmberApp = require('ember-cli/lib/broccoli/ember-app');

var app = new EmberApp({
  sassOptions: {
    includePaths: ['bower_components/normalize-scss']
  }
});

// Use `app.import` to add additional libraries to the generated
// output files.
//
// If you need to use different assets in different
// environments, specify an object as the first parameter. That
// object's keys should be the environment name and the values
// should be the asset to use in that environment.
//
// If the library that you are including contains AMD or ES6
// modules that you would like to import into your application
// please specify an object with the list of modules as keys
// along with the exports of each module as its value.

module.exports = app.toTree();

app.scss

$legacy_browser_support: true; /* to confirm SASS is working */
@import 'normalize';

from ember-cli-sass.

Yes its all open source and a volunteer effort, but you closed the issue when others are also experiencing the same problem which seems rather hasty. Maybe I am just old school but I've noticed so many projects close issues prematurely as part of their 'image' and real problems sit hidden away for the unwary who keep rediscovering and treading the same ground wasting time. Perhaps it would be better to tag as 'unconfirmed', 'needs test' or similar whilst ember-cli is in such a state of flux and then close out after the issue has gone stale (eg a month or two).

I don't expect others to solve my problem, to the contrary I've been forced to implement some alternative tooling that is two orders of magnitude faster than ember-cli for the all important edit/build/test cycle. There are significant performance issues with ember-cli and I invested time and energy into a novel approach for avoiding the issues that drove ember-cli performance into the ground, yet the ember-cli team seem to be ignoring the mass of users with unacceptable compile times and heading into a wilderness of symlink re-factoring which will take months before the dust settles with almost no likelihood of beating the performance of hard-links. Your closing of the issue seemed to confirm that the ember-cli fraternity doesn't appreciate that users out there are getting burnt because of the premature ember-cli marketing.

Did I want to develop my own tooling? No of course not, but I had to solve the problem because the tool authors don't seem tuned to the pain users are having. So I am no longer using ember-cli for the time being as much I really wanted to get on board with it. Ember cli has been a very disappointing experience and a case of over promising and significantly under-delivering. I plan to publish the setup I'm using very shortly as it works with the ember-cli file structure and I get 500ms builds so users can get some productivity back and their sass building working until the dust settles on ember-cli.

from ember-cli-sass.

@aexmachina Did you look at my example in the original issue? Your example does not match and does not work as expected. Attention to detail is important.

Mine:

 sassOptions: {
    includePaths: ['vendor', 'bower_components']
  }

Yours:

  sassOptions: {
    includePaths: ['bower_components/normalize-scss']
  }

How can you claim that is anything close to the same thing?

from ember-cli-sass.

My example is the correct way of doing it. You example will lead to very slow build times because you're providing the enter bower directory to your SASS compiler.

Furthermore I've just tried your way and have confirmed that it does work:

  sassOptions: {
    includePaths: ['bower_components']
  }

$legacy_browser_support: true; /* to confirm SASS is working */
@import 'normalize-scss/normalize';

@ahacking I'm not enjoying this exchange, and so I choose now to end it.

from ember-cli-sass.

Yeah slow build times are the norm with ember-cli even building a "hello world" app after "ember new" and when running on high end hardware. So its no surprise to hear that trying to really use it will slow down the build. That is not intended to be a cheap shot, just how ember-cli stacks up with other tooling.

There is a usability issue here then as we all have to specify the packages in bower.json, AND our brocfile AND our .SCCS file and that is not nice, hence the working approach I show in opening the issue above I chose to just pick manually out of bower_components from my app.scss

Libsass doesn't have any performance issue with using include paths, so it really is that ember-cli / broccoli is currently a defective toolchain when used on real apps.

I read your code and it looks like the cause of the problem must lie with brocolli-sass or brocolli proper but I'm not about to wade through that.

from ember-cli-sass.