Marcin Cieślak
Marcin Cieślak
Can everybody affected confirm they are using Visual Studio Code?
That is not a big issue. We could possibly drop the usage of request completely but this could mean some issues for users connecting via proxy.
@nhustak can you try `npm config set msbuild_path "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe"` ? See https://github.com/sass/node-sass/pull/2862 and https://github.com/nodejs/node-gyp/issues/1663 for more context
`getBinaryDir()` simply assumes things are located one level below. This should be be the case. Since we have introduced "humany-friendly" checks we fail in situations where plain `node` loading would...
Would that be possible to have some code to reproduce this?
1. `node-sass --importer node_modules/node-sass-glob-importer/dist/cli.js --output-style compressed -o $npm_package_config_public/css $npm_package_config_source/css2` does not watch. What is your invocation with `--watch` ? 2. Is it possible to reproduce this problem without `--importer node_modules/node-sass-glob-importer/dist/cli.js`...
Dropping binaries would be fantastic... I wonder how well will that setup perform
Wow, congratulations! Have you also rewritten libsass or has this been handled with emscripten? What is the node oldest version it can run on?
We provide only rudimentary watch facility (and it is not fully working even).
I think we should expose this. Maybe one day we will be able to [tell libsass which files need to be reloaded individually](https://github.com/sass/libsass/issues/1368).