Skip to content

compile fail with @import #119

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
otarim opened this issue Jul 14, 2015 · 8 comments
Closed

compile fail with @import #119

otarim opened this issue Jul 14, 2015 · 8 comments

Comments

@otarim
Copy link

otarim commented Jul 14, 2015

i create a repository to show this problem happen https://github.com/otarim/troubleshoot, it seems that sass-loader case this issue

1). run webpack --progress command and it compile fails, the stdout stay at

http://segmentfault.com/img/bVmHkV

2). use another entry file works.js and it passed

http://segmentfault.com/img/bVmHkX

3). i change sass-loader to less-loader and use less syntax,it works too

my node version is v0.12.2 working on mac os 10.10.1,thanks for your help:-)

@jorrit
Copy link
Contributor

jorrit commented Jul 14, 2015

It seems that this setup creates too many async operations, exhausting the internal libuv threads. For example, the following works:

UV_THREADPOOL_SIZE=10 npm start

No idea how this can be fixed in sass-loader.

@otarim
Copy link
Author

otarim commented Jul 14, 2015

@jorrit tks bro~your solution works for me 😄

@jorrit
Copy link
Contributor

jorrit commented Jul 14, 2015

Seems the same as sass/node-sass#857.

@jorrit
Copy link
Contributor

jorrit commented Jul 14, 2015

Maybe sass-loader can limit the number of outstanding sass render calls to UV_THREADPOOL_SIZE - 1 via the async module or something (no idea if that makes sense).
At least let's write down this UV_THREADPOOL_SIZE workaround somewhere in the README.

@otarim
Copy link
Author

otarim commented Jul 14, 2015

@jorrit agree~i spend all day working on this issue,until i replace less-loader with sass and it works, Otherwise I would have thought it's my wrong way usage,hope the author write down this workaround into README that someone else will not make the same mistake

@hoosin
Copy link

hoosin commented Jul 15, 2015

@otarim tks,I'll never make the same mistake again.

@jorrit
Copy link
Contributor

jorrit commented Jul 17, 2015

This is also a duplicate of #100, by the way. Let's close this issue.

Closes #119

@jhnns
Copy link
Member

jhnns commented Aug 6, 2015

Fixed with 2.0.0

@jhnns jhnns closed this as completed Aug 6, 2015
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants