-
Notifications
You must be signed in to change notification settings - Fork 1.3k
--include-path not working anymore in 4.4.0 #1876
Comments
I have an issue probably related to this as well. I'm using gulp-sass though. I have to specifically write |
@olivierbossel can you provide a minimal project that reproduces this along with with the actual command line and log |
@kaelig |
@nschonni I updated my comment. Here's a project you can test my issue in: https://github.com/salesforce-ux/design-system-starter-kit Steps to reproduce:
This error pops up:
|
@kaelig you're not providing any value for |
I thought the current directory was supposed to be in the includePaths by default (in that case: the root of the project from which the script is called)? |
No, https://github.com/sass/node-sass#includepaths. That causes problems because then it starts to try and pick up random packages (accidentally) published components. |
@nschonni |
Sorry the delayed response, Australian timezone and such. This is a bug. There was an unnecessary breaking change in LibSass regarding load paths. I missed this in the release notes for LibSass and forgot to compensate for it in node-sass. |
This is kind of true. @nschonni is correct in that node-sass isn't doing this. LibSass was internally adding the cwd of the entry file to it's internal search path, which is similar to user defined load paths. This was removed in LibSass 3.5.0 release line. Node Sass needs to be updated to shim the old behaviour for the time being.
@kaelig gulp-sass does add the cwd to the load path. |
It's not clear to me why you're experiencing the issue with gulp-sass and not node-sass. I would expect the inverse to be true. I'll have to investigate tonight. |
I am seeing this same issue as well. At first, I thought it as my gulp project where I am making lots of change so frequently. |
A work around for now is adding the cwd to your includePaths. |
You mean |
No, I mean in the
|
Hi there, Sorry for the delay (Switzerland timezone...). Let me know! :) |
Traditionally Sass has added the cwd as the first include path. This behaviour was remove in Sass 3.4, and recently in LibSass 3.5.0.beta.2. People depend on this behaviour and as a result a lot of compilations are now failing. This PR restores the expected behaviour and adds a test to boot. Fixes sass#1876
Traditionally Sass has added the cwd as the first include path. This behaviour was remove in Sass 3.4, and recently in LibSass 3.5.0.beta.2. People depend on this behaviour and as a result a lot of compilations are now failing. This PR restores the expected behaviour and adds a test to boot. Fixes sass#1876
npm -v
): 3.10.10node -v
): 6.9.4node -p process.versions
):Node Platform (
node -p process.platform
): darwinNode architecture (
node -p process.arch
): x64node-sass version (
node -p "require('node-sass').info"
):node-sass 4.4.0 (Wrapper) [JavaScript]
libsass 3.5.0.beta.2 (Sass Compiler) [C/C++]
npm node-sass versions (
npm ls node-sass
): 4.4.0Hi there,
Just to point out that the --include-path seems to not work anymore from this version. It was working in the node-sass 4.3.0 but not in the 4.4.0...
When I import some node_modules sass like:
it is yielding that the file is not readable. It works if I force the 4.3.0 version...
Hope this is not something to big to fix...
Let me know :)
Cheers guys, thanks for your work it's quite awesome!
Best regards
Olivier Bossel
The text was updated successfully, but these errors were encountered: