-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Problem with Node wrapper and "sassBinaryName" #691
Comments
Thanks for brining this to attention. I considered many angles to avoid version sniffing but missed this one. The real solution will come with the approach which will be finalised by: nodejs/node-gyp#564 (and used by nodejs/node-gyp#564). Workaround: So the standard "hacky" (version sniffing) approach is to add the following before node-sass (v2.0.1)/lib/extensions.js#L11: return runtimeVersion.major < 1 ? 'node' : 'iojs'; Note this^ workaround only applies to node-sass v2.0.1 (and its predecessor v2.0.0). With vNext we will replace it with a better alternative available at time. Note 2 with ref to #655; this approach is not feasible because it fails to detect atom-shell runtime. Also, it is not clear at this point whether or not we will be releasing binaries for atom-shell. |
This issue is addressed by #695. |
Improve custom importer to pass parent import context
When node-sass is installed with
npm install node-sass
or as dependency by another npm installation, binary binding is enclosed in a "OS-ARCH-node-VERSION" folder.Now, if app is launched with a node wrapper which
process.execPath
is not the node path, for example LiveScript (execPath = C:\Users\UserName\AppData\Roaming\npm\node_modules\LiveScript\bin\lsc)import
fails with Error:libsass
bindings not found because it search for "OS-ARCH-lsc-VERSION" folder.Should the binding name be dependent on the execPath mandatory?
Thanks :)
The text was updated successfully, but these errors were encountered: