node-sass: includePaths: ['node_modules'] doesn't work for scoped packages

source/css/style.scss:

@import "@scope/package-name/scss/style.scss";

Gruntfile.js:

module.exports = function(grunt) {
    grunt.initConfig({
            sass: {
                options: {
                    sourceMap: true,
                    includePaths: ['node_modules']
                },
                dist: {
                    files: {
                        'source/css/temp/style.css': 'source/css/style.scss'
                    }
                }
            }
    });

    // Plugins
    require('load-grunt-tasks')(grunt);

    // Tasks
    grunt.registerTask('default', ['sass']);
};

Error when grunt:

Running "sass:dist" (sass) task
>> Error: File to import not found or unreadable: @scope/package-name/style.scss
>>        Parent style sheet: D:/source/css/style.scss
>>         on line 103 of source/css/style.scss
>> >> @import "@scope/package-name/scss/style.scss";
>>    ^

When using the same package without scope, it works fine.

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 18 (7 by maintainers)

Most upvoted comments

you can try https://www.npmjs.com/package/node-sass-tilde-importer like so (in gulpfile)

const tildeImporter = require('node-sass-tilde-importer');
function compileSass(path, ext, file, callback) {
    let compiledCss = sass.renderSync({
        file: path,
        importer: tildeImporter,
        outputStyle: 'compressed',
    });
    callback(null, compiledCss.css);
}

I just tested it and it seems to do the job (although I didn’t test it with a scoped package)

Arikael on Sep 7, 2017

I got it. I’ve changed the includePaths value to node_modules/@scope. My includes are now relative to this path and it works.

XmlmXmlmX on Jun 21, 2016

I don’t see a way this can be integrated into the Sass language. The language implementation expose hooks to achieve this functionality. I believe this is the right approach. It enables the right approach and semantics to come out of the community.

Eyeglass is designed explicitly to solve Sass package via npm. It’s fully aware of npm’s import and version conflict resolution semantics.

I encourage you to contribute, or fork that project if need be.

On Thu., 12 Apr. 2018, 12:07 am Alasdair McLeay, notifications@github.com wrote:

~ is already an overloaded concept

sass-loader uses the concept that ~ without a slash is a lib import whereas ~/ is the home directory. That seems logical to me but I understand this introduces a breaking change.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sass/node-sass/issues/1596#issuecomment-380464756, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjZWAIx7w1ncQGXpjVKFVXFWMeWAj4Zks5tng4JgaJpZM4I4E98 .

xzyfer on Apr 11, 2018

This cannot be baked into the Sass language. LibSass alone is embedded into at least 18 different languages,each with their own packaging solution (if one exists at all).

Additionally ~ is already an overloaded concept meaning the users home directory.

This belongs in the realm of custom importers. A couple already exist for your use case. I suggest looking at eyeglass, or sass-loader if you’re using webpack.

On Wed., 11 Apr. 2018, 11:51 pm Alasdair McLeay, notifications@github.com wrote:

It would be good for the Sass language to infer that ~ means use your environments package resolution.

For node, adding a single node_modules to your path doesn’t account for:

node_modules that may be in a parent folder (common in monorepo structures)

globally installed modules

when used with npm link

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sass/node-sass/issues/1596#issuecomment-380459093, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjZWE_3dT0hyXL04Tu85clqt9wwyzyxks5tngpGgaJpZM4I4E98 .

xzyfer on Apr 11, 2018

It would be good for the Sass language to officially infer that ~ means use your environment’s package resolution, rather than this just being sass-loader specific syntax.

For node, adding a single node_modules to your path doesn’t account for:

node_modules that may be in a parent folder (common in monorepo structures)
globally installed modules
when used with npm link

Note that this was requested in https://github.com/sass/sass/issues/2350 but was closed with the comment:

As a rule, special resolution of imports are the domain of importer plugins, not the implementation itself. It’s possible that this makes sense for a wrapper, such as node-sass, but not for the core language.

This seems to conflict with this issue having the tags Discussion - Proposal Invalid - Not in Sass

penx on Apr 11, 2018