-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Add cache for downloaded binary files #1566
Conversation
- the binary file is downloaded to a tmp folder and copied to vendor destination. If the binary already exist in the tmp folder, it will be copied only. - With this change node-sass will work offline, cache the binary and save bandwidth. - The binary configuration parameters will work the same as before.
The code looks OK, but can't this just be achieved as-is by passing the temp directory (or the expression to test for what temp directory) to the existing SASS_BINARY_PATH |
I did read it, but apparently totally missed 2.
I think a general extension point for people wanting to change the download behaviour might be something to consider. |
@nschonni I'm not sure I'm following. The intent of this change is just changing the download directory from We will not be changing the directory structure at all so the version switching issue is no different than it is today. The thing that does changes is that I haven't had time confirmed the implementation here respects those constraints but it wont ship with out it. |
return; | ||
} | ||
var tmpPath = getTempPath(sass.getBinaryName()); | ||
if (!(sass.hasBinary(tmpPath))) { // download and install |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xzyfer this is the part I'm saying will always fall back to the first installed binary file in the temp folder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said I've haven't look over the implementation yet. It's entirely likely there are issues that will need to be addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name of the binary file in the tmp folder based on sass.getBinaryName()
. E.g. win32-x64-47_binding.node
, not just binding.node
. If you use another version of node-sass, the name will change too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're both correct. The binaries won't clash on different node/arch/os
combinations. However because we're no longer within node_modules changing
versions of node-sass would be an issue. When changing versions of
node-sass the installer would see a binary for their environment on disk
but it would not the correct binary for their node-sass version.
You'll need to create a folder for the node-sass version for this to work
as intended.
Exactly.
Correct. I kept everything the same, but split download and install the binary into two different steps and added a "temp layer". |
I think it goes towards a pretty good think. Can we have the cache format the same as for node-sass-binaries repository? In short, checking it out from git somewhere should be the easiest way to fill the cache. |
I think this approach is solid as long as the binaries are downloaded into |
I added the package version as subfolder to the temp path. It looks now like the file-structure of a release. Example: @saper, you should be able to easily fill the cache with scrips now. |
…cture as in releases
function getTempPath(binaryName) { | ||
var candidateTmpDirs = [ | ||
process.env.TMPDIR || process.env.TEMP || process.env.npm_config_tmp, | ||
'/tmp', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
process.env.TMPDIR is the same as os-tmpdir. Line 140 is a fallback, which should never be reached. These lines are copied from the install script of phantomjs. They use it long ago without any problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's ok, I'd still prefer you use a tested package that abstracts away this concern.
- simplify getTempPath() - use os-tmpdir - add fallback to vendor - remove unnecessary parameters
@xzyfer, still something missing, or does this this PR look good to you now? |
Sorry @mriehema we don't get notified of new commits so I didn't see these changes. |
*/ | ||
|
||
function getTempPath() { | ||
var candidateTmpDir = tmpdir() || process.env.npm_config_tmp; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't correct anymore. It's not either or, it's an array of candidates. What you used to have was correct.
var candidateTmpDirs = [
tmpdir(),
process.env.npm_config_tmp,
sass.getBinaryPath(),
];
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please take a look at the whole function. I removed the unnecessary foreach() loop of this list. It's now either tmpdir()
, or process.env.npm_config_tmp
. If they fail, sass.getBinaryPath()
is used as fallback.
Maybe we should (temporary) disable the skip_ci part of this install script to test it on your CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw the change and IMHO it's incorrect since tmpdir()
can never return a falsy value. Also, even if there is a tmpdir there is no guarantee it can be written to. The previous behaviour was correct because it asserted that either tmpdir()
or process.env.npm_config_tmp
existed and could be written to.
New order of operations 1. Look for existing binary in vendor folder 2. Create target vendor folder 3. Look to see if we’ve cached a copy in the NPM cache for this version 4. Download to current version’s cached NPM download 5. Copy the NPM cached version to the regular vendor directory Lookup the configured NPM cache folder. Closes sass#1566
New order of operations 1. Look for existing binary in vendor folder 2. Create target vendor folder 3. Look to see if we’ve cached a copy in the NPM cache for this version 4. Download to current version’s cached NPM download 5. Copy the NPM cached version to the regular vendor directory Lookup the configured NPM cache folder. Closes sass#1566
Closed. A) not mergable, B) see #1714 |
New order of operations 1. Look for existing binary in vendor folder 2. Create target vendor folder 3. Look to see if we’ve cached a copy in the configured or NPM cache 4. Download to current version’s /CACHE/node-sass/version/binding_file 5. Copy the cached download to the regular vendor directory Closes sass#1566
New order of operations 1. Look for existing binary in vendor folder 2. Create target vendor folder 3. Look to see if we’ve cached a copy in the configured or NPM cache 4. Download to current version’s /CACHE/node-sass/version/binding_file 5. Copy the cached download to the regular vendor directory Closes sass#1566
New order of operations 1. Look for existing binary in vendor folder 2. Create target vendor folder 3. Look to see if we’ve cached a copy in the configured or NPM cache 4. Download to current version’s /CACHE/node-sass/version/binding_file 5. Copy the cached download to the regular vendor directory Closes sass#1566
Fixes #1554.