Impossible to mirror the libsass binaries

[npiguet]

After having investigated the proxy issue, I found out an extra problem: Even when the proxy call is made to work, my corporate proxy does not allow downloading native executables (.so, .dll, etc..) from the internet. The binaries provided by node-sass are blocked by the proxy and prevent the proper installation of node-sass.

As a workaround for this kind of issues, my organisation has an internal server dedicated to hosting trusted binaries that can be accessed without going through the proxy. That sounded like a reasonable solution to my problem until I disovered how the path to the binary is resolved:

function getBinaryUrl() {
  return flags.binaryUrl ||
         package.nodeSassConfig ? package.nodeSassConfig.binaryUrl : null ||
         process.env.SASS_BINARY_URL ||
         ['https://github.com/sass/node-sass/releases/download//v',
          `package.version, '/', sass.binaryName].join('');
}

and

function getBinaryName() {
  var binaryName;

  if (flags.binaryName) {
    binaryName = flags.binaryName;
  } else if (package.nodeSassConfig && package.nodeSassConfig.binaryName) {
    binaryName = package.nodeSassConfig.binaryName;
  } else if (process.env.SASS_BINARY_NAME) {
    binaryName = process.env.SASS_BINARY_NAME;
  } else {
    binaryName = [process.platform, '-',
                  process.arch, '-',
                  process.versions.modules].join('');
  }

  return [binaryName, 'binding.node'].join('_');
}

This means that if I want to override the location of the binary, I need to point to the exact location of the particular binary that works for each machine's platform/architecture/module version/node-sass version combination. This is currently pretty hard to do given the various environments that our build scripts must run on.

node-sass should provide an option, say --sass-binary-mirror-url, that allows me to build a dumb mirror of all the binaries and that tells the node-sass installer to perform its binary resolution algorithm using this URL as base (instead of the hardcoded https://github.com/sass/node-sass/releases/download/)

As a workaround, I guess I could copy both of these methods to my gulpfile.js and compute the binary URL there. However, I'm not sure how I could make node-sass pick up that url. Is it possible?

[saper]

Maybe we could use npmconf for this?

[am11]

The OP probably need what phantomJS does: provide the ability to mirror the CDN. We are half way through. I thought it would make no sense to provide same organisation as we have in our own setup, so I didn't provided the same naming scheme as we have in node-sass. Given this use-case, I am pretty convinced and we would augment the same name as our (or probably configurable format via package.json). All the abilities are available in extensions.js but they need to be tested thoroughly.

Related: #743.

[saper]

I think @npiguet needs something like this 65b0519 and set SASS_DIST_SITE accordingly.

[npiguet]

I can confirm that this sounds exactly like what I need.

On April 4, 2015 10:25:16 PM Marcin Cieślak notifications@github.com wrote:

I think @npiguet needs something like this 62d991c and set SASS_DIST_SITE
accordingly.

---

Reply to this email directly or view it on GitHub:
#775 (comment)

[chriseppstein]

👍 This is a blocker issue for us at LinkedIn.

[saper]

@chriseppstein Our premium support customers are always a top priority for us, can you try applying pull request #835 and set SASS_BINARY_SITE environment variable to the root of your mirror?

[chriseppstein]

@saper Thank you for the quick turn-around!

Hey, @winding-lines, does this look sufficient for our needs?

[chriseppstein]

Actually, @dosco is going to be looking into this :)

[dosco]

@saper will try and get an update to you about the patch by tomorrow.

[saper]

Which timezone? :)

[dosco]

@saper @chriseppstein I had a chance to test the patch locally against our repository and it works great.

[saper]

Thanks, I just uploaded the hopefully final version of the patch.

[xzyfer]

Catching up. @saper that patch looks reasonable for the time being. Please open PR. I'll aim to get it into 3.0.0.

My only suggestion would be put the default url into the package.json.

[saper]

On Wed, 22 Apr 2015, Michael Mifsud wrote: My only suggestion would be put the default url into the `package.json`.

Good idea, will update in #835. What do you think about test refactoring?

[xzyfer]

Apologies I missed your PR. Let's move this discussion to #835.