WebCompiler
WebCompiler copied to clipboard
cant work in linux
Installed product versions
- Visual Studio: 2022
- This extension: 1.14.8
Description
can't work in linux,terminal print info
WebCompiler: Begin compiling compilerconfig.json
WebCompiler installing updated versions of the compilers...
⛔/var/jenkins_home/.nuget/packages/buildwebcompiler2022/1.14.8/build/BuildWebCompiler2022.targets(12,9): error : An error occurred trying to start process 'cmd.exe' with working directory '/tmp/WebCompiler1.14.8'. No such file or directory
Steps to recreate
- upload source files at linux server
- run "dotnet publish -c Release"
Current behavior
run build in linux will error
Expected behavior
run build in linux will success
Pull Requests welcome.
Hi all - I've had a go at updating the code to support OS X + Linux. The implementation is 95% working. See #82
@failwyn Is it ok if I disable node-sass for Unix? It's deprecated, and I can't get the latest version to install or run under Unix. Users will still have the default (Dart) Sass compiler that's recommended in the node-sass repo's description.
Whilst I'm not really a web dev and thus not so familiar with the sass development in the past, I'd advocate for dropping node-sass support entirely (in a different issue/pr). This has to do with the way the node_modules folder is created. The build/build.cmd
script pre-installs all the NPM packages locally & zips all of them. This zip then gets released with the NuGet package - and that's where the issue lies: The platform that compiles the NuGet package defines the NPM packages that get released - for any execution platform.
To be able to be fully compatible with Unix, there's a build/build.sh
script now that does the same for Unix - but when we remove node-sass from the installation list in the shell script (because the installation¹ fails on Unix), we'd release different NPM packages, depending on the platform where the NuGet package is compiled.
This would mean (assuming we'd disable the node-sass execution in the code and tell the user it's unavailable for Unix):
/ | Release on Unix | Release on Windows |
---|---|---|
Run on Unix | all fine (not supported) | all fine (not supported) |
Run on Windows | error because package is not in node_modules (although supported) |
all fine (supported) |
But when I understood it correctly, you'd compile and release from Windows anyway. This would circumvent the problem for now.
To eliminate the problem, we could do one of two things
- I don't know what your long-term plans with the package's architecture are, but we'd have to get to a point where the NuGet package doesn't bring all of its NPM package dependencies in a zip but rather installs them locally on the fly (but I haven't looked deeper into this as it's out of scope for this issue). The Windows version would then install node-sass, the Unix one not.
- Drop node-sass support for the whole project
As I already wrote, I'm in favor of option 2 as node-sass is deprecated anyway and having different feature sets for different platforms doesn't feel right. But that's nothing that has to be decided now, as long as you're fine with disabling node-sass for Unix and you continue to compile the released NuGet package on Windows.
¹ It's not just the native installation on Unix - also running the Windows-compiled NuGet package on Unix doesn't work for node-sass