Skip to content
This repository has been archived by the owner on Jul 24, 2024. It is now read-only.

The compiled binary should be also cached. #1882

Closed
abcfy2 opened this issue Feb 3, 2017 · 4 comments
Closed

The compiled binary should be also cached. #1882

abcfy2 opened this issue Feb 3, 2017 · 4 comments

Comments

@abcfy2
Copy link

abcfy2 commented Feb 3, 2017

  • NPM version (npm -v): 4.1.2
  • Node version (node -v): v6.9.5
  • Node Process (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: '56.1',
  modules: '48',
  openssl: '1.0.2k' }
  • Node Platform (node -p process.platform): linux
  • Node architecture (node -p process.arch): x64
  • node-sass version (node -p "require('node-sass').info"):
node-sass	4.5.0	(Wrapper)	[JavaScript]
libsass  	3.5.0.beta.2	(Sass Compiler)	[C/C++]
  • npm node-sass versions (npm ls node-sass):
└─┬ angular-cli@1.0.0-beta.28.3
  └── node-sass@4.5.0

I find the compiled binary not be cached in ~/.npm/node-sass. So If the node-modules/ dir removed will download or compile again.

tree ~/.npm/node-sass
/home/fengyu/.npm/node-sass
├── 3.13.1
│   ├── linux-x64-48_binding.node
│   ├── package
│   │   └── package.json
│   └── package.tgz
├── 4.2.0
│   ├── package
│   │   └── package.json
│   └── package.tgz
├── 4.3.0
│   ├── linux-x64-48_binding.node
│   ├── package
│   │   └── package.json
│   └── package.tgz
└── 4.5.0
    ├── package
    │   └── package.json
    └── package.tgz

8 directories, 10 files

If the downloading pre-compiled binary failed(4.5.0), and the compiled binary not be cached in ~/.npm/node-sass/. I think it's better to cache the compiled binary as well.

@xzyfer
Copy link
Contributor

xzyfer commented Feb 3, 2017

I don't understand. If the binary fails to download how can we cache the downloaded binary?

@abcfy2
Copy link
Author

abcfy2 commented Feb 3, 2017

Sorry, I mean that we should cache the compiled binary as well.

If downloading failed --> Compile binary from source. The compiled binary should be also cached, so that if we delete the node-modules/ directory, will not download or compile again.

@abcfy2
Copy link
Author

abcfy2 commented Feb 6, 2017

Maybe just add a addition step after compile binary from source: copy compiled binary to ~/.npm/node-sass/${VERSION}.

@mycoin
Copy link

mycoin commented Feb 6, 2017

darwin-x64-46_binding.node is to large, so the installing always be timeout.

> node-sass@4.0.0 install /Users/apple/Downloads/react-slingshot/node_modules/node-sass
> node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.0.0/darwin-x64-46_binding.node
Cannot download "https://github.com/sass/node-sass/releases/download/v4.0.0/darwin-x64-46_binding.node": 

ESOCKETTIMEDOUT

Hint: If github.com is not accessible in your location
      try setting a proxy via HTTP_PROXY, e.g. 

      export HTTP_PROXY=http://example.com:1234

or configure npm proxy via

      npm config set proxy http://example.com:8080

xzyfer added a commit to xzyfer/node-sass that referenced this issue Feb 22, 2017
Currently the binary download is streamed to disk once a 200 response
has been recieved. When an error occurs during the download a partially
downloaded binary is left on disk. Subsequent installs see the binary
and bail out of re-downloading it. Worse yet those subsequent installs
move the binary into the global cache so even removing node_modules
will not remove the broken binary.

With this patch the binary is only flushed to disk once it has been
fully downloaded.

Fixes sass#1882
Fixes sass#1888
xzyfer added a commit to xzyfer/node-sass that referenced this issue Feb 22, 2017
Currently the binary download is streamed to disk once a 200 response
has been recieved. When an error occurs during the download a partially
downloaded binary is left on disk. Subsequent installs see the binary
and bail out of re-downloading it. Worse yet those subsequent installs
move the binary into the global cache so even removing node_modules
will not remove the broken binary.

With this patch the binary is only flushed to disk once it has been
fully downloaded.

Fixes sass#1882
Fixes sass#1888
xzyfer added a commit to xzyfer/node-sass that referenced this issue Mar 10, 2018
Currently the binary download is streamed to disk once a 200 response
has been recieved. When an error occurs during the download a partially
downloaded binary is left on disk. Subsequent installs see the binary
and bail out of re-downloading it. Worse yet those subsequent installs
move the binary into the global cache so even removing node_modules
will not remove the broken binary.

With this patch the binary is only flushed to disk once it has been
fully downloaded.

Fixes sass#1882
Fixes sass#1888
xzyfer added a commit that referenced this issue Mar 10, 2018
Currently the binary download is streamed to disk once a 200 response
has been recieved. When an error occurs during the download a partially
downloaded binary is left on disk. Subsequent installs see the binary
and bail out of re-downloading it. Worse yet those subsequent installs
move the binary into the global cache so even removing node_modules
will not remove the broken binary.

With this patch the binary is only flushed to disk once it has been
fully downloaded.

Fixes #1882
Fixes #1888
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Projects
None yet
Development

No branches or pull requests

4 participants