WebCompiler icon indicating copy to clipboard operation
WebCompiler copied to clipboard

cant work in linux

Open comvir opened this issue 2 years ago • 3 comments

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

  1. upload source files at linux server
  2. run "dotnet publish -c Release"

Current behavior

run build in linux will error

Expected behavior

run build in linux will success

comvir avatar Jan 11 '23 07:01 comvir

Pull Requests welcome.

failwyn avatar Jan 11 '23 13:01 failwyn

Hi all - I've had a go at updating the code to support OS X + Linux. The implementation is 95% working. See #82

garyhuntddn avatar Jun 20 '23 01:06 garyhuntddn

@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

  1. 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.
  2. 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

Velociraptor45 avatar Sep 02 '23 08:09 Velociraptor45