Importing file (support-for) does not exist

[jrock2004]

The first import that normalize does is for a file that does not exist. Any ideas?

It seems that in this commit f32a7fdae314297ee053d6588d7ea913aeb7fb4b , it was removed from the normalized folder.

[benweier]

Looks like support-for was removed from the normalize folder in favour of the support-for external package instead. I fixed this by adding node_modules/support-for/sass to my include paths.

Your specific implementation of this workaround will depend on which tool you use to compile your Sass.

[JohnAlbin]

How did you install normalize-scss? Both npm and gem/bundler should install support-for automatically.

But, yeah, the include path thing is a pain. My solution for this is the same as @benweier's:

I fixed this by adding node_modules/support-for/sass to my include paths.

Your specific implementation of this workaround will depend on which tool you use to compile your Sass.

[jrock2004]

I used bower

[JohnAlbin]

Okay. I just confirmed that bower, at least, does download support-for when requesting normalize.scss.

$ bower install --save-dev normalize.scss
bower normalize.scss#*          cached git://github.com/JohnAlbin/normalize-scss.git#4.0.1
bower normalize.scss#*        validate 4.0.1 against git://github.com/JohnAlbin/normalize-scss.git#*
bower support-for#~1.0.2        cached git://github.com/JohnAlbin/support-for.git#1.0.2
bower support-for#~1.0.2      validate 1.0.2 against git://github.com/JohnAlbin/support-for.git#~1.0.2
bower normalize-scss#~4.0.1    install normalize-scss#4.0.1
bower support-for#~1.0.2       install support-for#1.0.2

normalize-scss#4.0.1 bower_components/normalize-scss
└── support-for#1.0.2

support-for#1.0.2 bower_components/support-for

How do you normally get a bower component's include path into node-sass? Manually register it? (I want to document this better.)

The includePaths is an awkward part of node-sass. And I haven't been using it long enough to know if there is a better way.

[benweier]

Manually registering the path is probably the best way. I'm not aware of any tools that will automatically pick them up.

Using Gulp I'm passing includePaths to the sass command:

gulp.task('sass', function () {
  gulp.src('./sass/*.scss')
      .pipe(sass({
        includePaths: [
          'path/to/bower_components/support-for/sass',
          'path/to/bower_components/normalize-scss/sass'
        ],
      }))
      .pipe(gulp.dest('./css'));
});

It's similar for Grunt:

grunt.initConfig({
  sass: {
    options: {
      includePaths: [
        'path/to/bower_components//support-for/sass',
        'path/to/bower_components/normalize-scss/sass'
      ]
    },
    dist: {
      files: {
        'main.css': 'main.scss'
      }
    }
  }
});

Or node-sass directly (I haven't used this option so I've C&P'd their example):

var sass = require('node-sass');
sass.render({
  file: scss_filename,
  includePaths: [
    'path/to/bower_components//support-for/sass',
    'path/to/bower_components/normalize-scss/sass'
  ]
}, function(err, result) { /*...*/ });

I hope this helps!

[Undistraction]

This is a problem when using Webpack as well, requiring two sets of paths:

sassLoader: {
    includePaths: [path.join(node_dir, 'normalize-scss', 'sass'), path.join(node_dir, 'normalize-scss', 'node_modules', 'support-for', 'sass')]
  },

[JohnAlbin]

@Undistraction Thanks for the info! Is the "node_dir" a standard thing when doing Webpack? or is that just a local JS variable from your gulpfile?

[pathetix]

I have the same problem. Using Codekit V2.3.1

[michaelrkn]

This also happens with Sprockets:

Sass::SyntaxError: File to import not found or unreadable: support-for.
Load paths:
  /Users/michael/Code/guides/source/stylesheets
  /Users/michael/.gem/ruby/2.2.2/gems/compass-core-1.0.3/stylesheets
  Compass::SpriteImporter
  /Users/michael/.gem/ruby/2.2.2/gems/normalize-scss-4.0.0/sass
  /Users/michael/.gem/ruby/2.2.2/gems/bourbon-4.2.6/app/assets/stylesheets
  /Users/michael/.gem/ruby/2.2.2/gems/neat-1.7.2/app/assets/stylesheets
  /Users/michael/.gem/ruby/2.2.2/gems/normalize-scss-4.0.0/sass
  /Users/michael/.gem/ruby/2.2.2/gems/bourbon-4.2.6/app/assets/stylesheets
  /Users/michael/.gem/ruby/2.2.2/gems/neat-1.7.2/app/assets/stylesheets
  (in /Users/michael/Code/guides/source/stylesheets/application.css.scss:1)

I'm using Middleman, and fixed it by adding to my config.rb:

compass_config { |c| c.add_import_path(Bundler.rubygems.find_name('support-for').first.full_gem_path + "/sass") }

[Undistraction]

Yep. node_dir is just a variable I use elsewhere. I think this issue can be easily sorted by using a relative path to the dependency.

On Thu, 3 Dec 2015, 08:49 pathetix notifications@github.com wrote:

I have the same problem. Using Codekit V2.3.1

— Reply to this email directly or view it on GitHub https://github.com/JohnAlbin/normalize-scss/issues/43#issuecomment-161554689 .

[jrock2004]

So looking at where this is currently at for bower installs.

bower_components normalize-scss support-for

From this you I assume we need to copy the support-for/sass/_support-for.scss to normalize-scss/sass directory. I am happy to fork the directory and do the work for this. My question is, would I write the ruby code in normalize-scss.rb to do this? If you point me in te write direction I would like to help

[jrock2004]

Here is my attempt to see if this works. Take a look at my attempt. If this looks right, let me know and I can create pull request [https://github.com/JohnAlbin/normalize-scss/compare/master...jrock2004:master]

[catalinux]

When working with gem and compass you need to add the following lines

Gemfile

gem "support-for"

config.rb:

require 'support-for'

[michaelrkn]

@catalinux Thanks, that's much cleaner than my solution.

[esr360]

I've installed this as a git submodule and ran npm install, but whem importing normalize I keep getting this error:

File to import not found or unreadable: support-for.

How do I get around this issue?

EDIT: I fixed this by changing the path for 'support-for' to:

@import '../node_modules/support-for/sass/support-for';

but if I ever update the repo I will have to re-make this change...

[catalinux]

@esr360 : did you try my solution?

[esr360]

@catalinux, I need an out-the-box solution. I intend to distribute a theme which uses normalize-scss and can't require my users to add custom configuration lines.

[catalinux]

Ok. The problem is that the last verion of normalize-scss (4.x) does not include include support-for anymore. So you need to use also library support-for. As your theme has normalize-scss dependency , you can add also support-for dependency. You can setup these dependencies in your Gemfile like this

source "http://rubygems.org"

gem "normalize-scss"
gem "support-for"

[esr360]

Great, thank you very much I will try your suggestion.

[deathmood]

it is VERY annoying ---- so i can not just include normalize in my main sass file and it works. And if I do not use neither grunt nor gulp --- then I need to have looooong command line to just build it (I do not use ruby - only node)

---

UPDATE:

If someone also does not need configuration --- just use node-normalize-scss

[JohnAlbin]

I couldn't figure out why normalize-scss has all of these issues when breakpoint (which depends on sassy-maps) does not have these issue.

I investigated this further and discovered that breakpoint declares a dependency in its package.json, but only conditionally uses sassy-maps if one of its functions is defined. guh

The inability of node-sass to easily handle importPaths of Sass libraries and their dependencies is annoying.

I'm going to de-fork support-for and bring a copy of it back into normalize-scss. :-p

[evolutionxbox]

"I use bower" isn't a great answer. I don't use gulp or grunt, but I do use bower. I still face these strange dependency issues no matter what approach I seem to take.

[JohnAlbin]

don't use gulp or grunt, but I do use bower. I still face these strange dependency issues no matter what approach I seem to take.

Bower does not compile Sass.

[evolutionxbox]

I never thought it did. I just use @import 'bower_components/normalize-scss/sass/normalize' in my main.scss file.

[JohnAlbin]

This issue may be fixed in 4.1.0. https://github.com/JohnAlbin/normalize-scss/commit/55d5719de0b498f140d43958843a45c4224d7ea3

[esr360]

Yes! Amazing news.

[bpmckee]

@JohnAlbin I'm using 4.1.0 and I still have to include the node_modules paths in order to get it to work.

[esr360]

@bpmckee I am using 4.1.0, and all I am doing is:

@import "vendor/normalize-scss/sass/normalize";

And that's it, it works perfectly. 4.1.0 comes with support-for included, so there shouldn't be any issues relating to this bug I don't think.

[bpmckee]

@esr360 Ahhh I see! I thought there was some strange magic happening behind the scenes that would make it so you can just do

@import "normalize";

[JohnAlbin]

The "magic" is when normalize's path (path/to/installation/normalize-scss/sass) is added to node-sass' includePaths option or to Ruby Sass' --load-path.

Then Sass/node-sass will know that when you say @import "normalize"; to look in all the include paths for (_)?normalize.s[ac]ss

This whole problem started because I thought many build tools provided a mechanism to easily add include paths and to figure out dependencies and their paths, but that turned out not to be the case. Looks like I need to update the docs some more.

Thank you to everyone who commented in this thread. I learned a lot and appreciate your input.