node-sass install caught in infinite loop #2006
Comments
|
Probably interesting combination of a node-gyp issue (poor fallback on lack of permissions) and npm bug (infinite retry). npm 5 is hard to get working, does downgrade help? |
|
Yeah, it only happens in npm 5. I think the infinite retry is likely node-gyp's issue. Solved the permissions issue by the tried-and-true method of |
|
Probably the same as nodejs/node-gyp#115 |
Referencing sass/node-sass#2006 in fix
|
Same problem, I solved it like this thanks to @thomblake |
|
same problem also on npm 5.5.1 either still solved with: node-sass 4.7.2 (Wrapper) [JavaScript] |
|
Closing as this only appears to be an issue that happens when installing as root as documented by NPM https://docs.npmjs.com/misc/config#unsafe-perm |
|
This doesn't seem resolved. Installing node-sass globally fails when not run as root, and loops infinitely when run as root. Is the expectation that node-sass must not be installed globally, or the user must pass --unsafe-perm when installing globally? |
|
We don't recommend installing anything globally. We suggest using npx. If
you must then you'll need the --unsafe-perms flag for any module with post
install scripts
…On 21 Mar. 2018 1:32 pm, "Kyle Ferriter" ***@***.***> wrote:
This doesn't seem resolved. Installing node-sass globally fails when not
run as root, and loops infinitely when run as root.
Is the expectation that node-sass must not be installed globally, or the
user must pass --unsafe-perm when installing globally?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2006 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAjZWD3qchqMeoVcZ_l94DUHAgNdLCQMks5tgbvPgaJpZM4N0mJv>
.
|
|
You can try to change your node version with the recommended LTS. with nvm On my mac I did this:
It fixed my problem without changing npm permission ;) |
LibSass fully parses selectors during the parsing stage. This is different from Ruby Sass which parse selectors and string during the parsing stage, and lazily eval'ing when required. This difference causes some pathological selector issues. Our eager parsing of selectors has resulted in us hacking in fake `Parent_Selector` into `Sequence_Selector` during parsing. These fake `Parent_Selector` play havoc with `resolve_parent_refs` when within `@at-root` blocks. I spent a couple weeks going down the rabbit whole of refactoring our selector parsing to be lazy before bailing. Explicitly marking which `Parent_Selector` are fake during parsing allows us faithfully implement the `implicit_parent` flag in `resolve_parent_refs`. Fixes sass#2006 Fixes sass#2198 Spec sass/sass-spec#936
This is in a Docker container using npm 5. I'm not sure how reproducible it is, but I thought it would be of interest anyway. It's possible that this happens because the temporary directory it's trying to use as a backup is the same as the install directory.
I can probably fix this by fixing my permissions, but an infinite loop seems undesirable.
npm -v):5.0.3
node -v):6.9.5
node -p process.versions):{ http_parser: '2.7.0',
node: '6.9.5',
v8: '5.1.281.89',
uv: '1.9.1',
zlib: '1.2.8',
ares: '1.10.1-DEV',
icu: '57.1',
modules: '48',
openssl: '1.0.2k' }
node -p process.platform):linux
node -p process.arch):x64
node -p "require('node-sass').info"):node-sass 3.13.1 (Wrapper) [JavaScript]
libsass 3.3.6 (Sass Compiler) [C/C++]
npm ls node-sass):Log snippet:
(continues like that forever)
The text was updated successfully, but these errors were encountered: