Node-sass: Allow binaries to be install from the local filesystem

[xzyfer]

Originally mentioned in https://github.com/sass/node-sass/issues/1104#issuecomment-134525186

Problem

Currently the binary site config, as the name suggests, needs to be a remote URL. Allowing file access might be useful for local development.

Proposed solution

 set SASS_BINARY_LOCATION=C:/tmp/node-sass-bin-mirror
 npm install node-sass

Usecase

To be honest I'm not entire sure this is useful. The major usecase I see for this is offline development.

Thoughts @am11 @saper?

[xzyfer]

@flogehring this may be of interest to you.

[flogehring]

Yes, that and

 "nodeSassConfig": {
   "binarySite": "C:/temp/node-sass-bin-mirror/"
},

would both be helpful for offline development or development behind annoying corporate proxies

[am11]

At present it is quite possible. Also, the install script skips the binary download (not sure if we documented it properly, these details are buried in some PR description):

Bash version:

mkdir /test-sass
cd /test-sass

# download / copy binding.node in /test-sass, then:
SASS_BINARY_PATH=/test-sass/binding.node npm install node-sass

CMD version:

mkdir \test-sass
cd \test-sass

:: download / copy binding.node in c:\test-sass, then:
SET SASS_BINARY_PATH=C:/test-sass/binding.node
:: your drive letter may vary

npm install node-sass

PowerShell version:

mkdir /test-sass
cd /test-sass

# download / copy binding.node in c:\test-sass, then:
$env:SASS_BINARY_PATH="C:/test-sass/binding.node"
# your drive-letter may vary

npm install node-sass

package.json version:

"nodeSassConfig": {
  "binaryPath": "/test-sass/binding.node"
}

[xzyfer]

Argh you're totally right. Completely forgot about SASS_BINARY_PATH. It comes up so rarely.

I'm glad I asked the question.

[saper]

I think we could consider adding support for this to SASS_BINARY_SITE (maybe renamed again:) - it can be useful for folks sharing node installations via UNC shares ('\Server\disk').

[xzyfer]

@saper according to @am11 this is already available but under the SASS_BINARY_PATH variable instead. May be there's a case for combining the two and determining whether it's an FS or network operation at runtime.

[saper]

Those two are not equivalent: SASS_BINARY_PATH points at the ultimate location of the binding file - it must match your node-sass version, architecture and the node engine. A repository pointed to by SASS_BINARY_SITE can contain multiple node versions, architectures, and engines - much like our github binary repository. I would have expected to have those re-used via some shared, but non-HTTP path in a closed environment.

[am11]

@xzyfer, we have:

SASS_BINARY_NAME
SASS_BINARY_SITE
SASS_BINARY_PATH

At the time, I thought this will suffice most of the needs for the original/first requesters, which it did. I took some inspirations form PhantomJS project.
But as always, there is a room for enhancement and as I see it, path to enhancement is paved with zero obstacles here.

[xzyfer]

Tracking documentation of these, and other, ENV variables in https://github.com/sass/node-sass/issues/1143

[DominicTobias]

If I do:

"nodeSassConfig": {
  "binaryPath": "test-sass/binding.node" // or ./path/to/local/file
}

It seems it is ignored and npm i node-sass --save-dev with Windows and Node 9.8.0 still tries to download the binary from GitHub and then falls back to compiling a binary. How can I get it to work?

Also tried setting a global SASS_BINARY_PATH with an absolute path but it's ignored too (and less desirable anyway).

Thanks

[am11]

Unfortunately, package.json option currently is only applicable if you have the option set in node-sass' own package.json while developing node-sass.

For npm-install, according to https://docs.npmjs.com/misc/scripts#packagejson-vars, we could add something like (untested):

--- a/lib/extensions.js
+++ b/lib/extensions.js
@@ -191,6 +191,8 @@ function getBinaryName() {
     binaryName = process.env.npm_config_sass_binary_name;
   } else if (pkg.nodeSassConfig && pkg.nodeSassConfig.binaryName) {
     binaryName = pkg.nodeSassConfig.binaryName;
+  } else if (process.env.npm_package_nodeSassConfig_binaryName) {
+    binaryName = process.env.npm_package_nodeSassConfig_binaryName;
   } else {
     variant = getPlatformVariant();
     if (variant) {
@@ -270,6 +272,8 @@ function getBinaryDir() {
     binaryDir = process.env.npm_config_sass_binary_dir;
   } else if (pkg.nodeSassConfig && pkg.nodeSassConfig.binaryDir) {
     binaryDir = pkg.nodeSassConfig.binaryDir;
+  } else if (process.env.npm_package_nodeSassConfig_binaryDir) {
+    binaryDir = process.env.npm_package_nodeSassConfig_binaryDir;
   } else {
     binaryDir = defaultBinaryDir;
   }
@@ -302,6 +306,8 @@ function getBinaryPath() {
     binaryPath = process.env.npm_config_sass_binary_path;
   } else if (pkg.nodeSassConfig && pkg.nodeSassConfig.binaryPath) {
     binaryPath = pkg.nodeSassConfig.binaryPath;
+  } else if (process.env.npm_package_nodeSassConfig_binaryPath) {
+    binaryPath = process.env.npm_package_nodeSassConfig_binaryPath;
   } else {
     binaryPath = path.join(getBinaryDir(), getBinaryName().replace(/_(?=binding\.node)/, '/'));
   }

Also tried setting a global SASS_BINARY_PATH with an absolute path but it's ignored too

This scenario appears to be working. I have binding.node file in c:\temp (note name of the file is fixed unless overridden by SASS_BINARY_NAME EDIT: not precisely, as long as environment has alternative path set with custom filename, it works, although .node extension is a hard requirement of C++ addons):

SET SASS_BINARY_PATH=C:\temp\binding.node
npm i node-sass --save-dev

...
Binary found at C:\temp\binding.node
Testing binary
Binary is fine

[DominicTobias]

Thanks @am11, I'll try SASS_BINARY_PATH again. But yes I think it would be very to have so that behind corporate firewalls a project can be installed without any extra steps!