Windows Host - Linux Execution Platform. Plugin not working when working remotely over a "Remote SSH" extension

[Jes3-a]

Local OS: Win10
VSCode v: 1.63.2
DartJS Sass Compiler and Sass Watcher v: 0.8.8
Sass v: 1.47.0

Sass location: C:\Users\myusername\AppData\Roaming\npm\node_modules\sass

I've tried just about everything. I tried installing sass locally and globally.

I'm currently using "Remote - SSH" extension to edit SCSS files remotely within vscode. If it matters, the remote OS is Ubuntu 20.04 LTS

I am able to compile the SCSS root file by editing the root file, or hitting F1 and then running the DartJS compile current file command. However, if I edit any _file.scss file, the root SCSS file does not recompile, probably because the folder is not being watched by Sass, probably because DartJS is unable to find the Sass binary.

The error says the path does not exist... however:

As evidenced by that image, the path does, in fact, exist.

Also, inside of my settings.json file, this is what my dartjs extension settings looks like:

I no longer know what to do. I have tried everything. I need for this to work. :)

Please help. Mucho gracias, senior. Por favor. Salsa con queso. Dorito.

[akkumar]

Thanks, @Jes3-a for the detailed reproduction steps.

If I understand correctly - you are working on a Windows host machine ( You had mentioned something about "Remote SSH" extension - not familiar with it until now so I need to check the same ).

Meanwhile - if it is a windows box you are working on - the instructions for sassBinPath for windows are slightly different from that of Linux.

See Local Sass Binary installation in README.md for more details.

Specifically - it should be - node_modules\sass\sass.js for windows.

[Jes3-a]

See Local Sass Binary installation in README.md for more details.

Specifically - it should be - node_modules\sass\sass.js for windows.

Understood. I have changed the Sass Bin path to node_modules\sass\sass.js as you suggested:

I received the same error as usual:

So, I restarted VSCode. Upon restarting, I received this error:

[akkumar]

In your first message - the project root seems to be on windows.

In the second message - you mentioned the project root that seems to be on Linux.

So - which is the project root being used ?

All along the plugin assumed that the machine (or OS) being developed is the same as where it gets compiled as well.

It seems the quirkiness of having the host platform ( Windows , in this case ) and the execution platform ( Ubuntu , in this case) seems to be the problem.

For now - the plugin assumes they are the same.

In the case you had brought up - they seem to be different and hence the quirkiness comes up. This might require some revisiting the code and debugging . I am sorry I dont have a quick answer to this right away - but something I would definitely look into and fixing soon.

[Neltulz]

To be fair, I had no idea of the concept of Project Root until mere days ago. I am not a VS Code expert. I've used it for a few years now and I'm quite good at editing HTML/CSS/JS files and then uploading them back to my server via SCP with WinSCP, but connecting to my server via SSH and learning SCSS compilation is an entirely new concept to me, and I'm having to learn all sorts of stuff I don't understand.

In summary: I'm tackling 2 new things that I've never done before up until only a few days ago (Remote SSH & SCSS compilation).

So - which is the project root being used ?

I think it has something to do with the Remote SSH extension.

When I start VS Code, this message appears in the bottom right corner:

And then at the top of VS Code, this is what appears:

Once I type in my SSH password, it connects, and then the explorer is populated like this:

I am noticing a node_modules folder there. I tried setting the sass location to that but I didn't have much luck and I gave up.

All along the plugin assumed that the machine (or OS) being developed is the same as where it gets compiled as well.

It seems the quirkiness of having the host platform ( Windows , in this case ) and the execution platform ( Ubuntu , in this case) seems to be the problem.

I sort of understand.

In the case you had brought up - they seem to be different and hence the quirkiness comes up. This might require some revisiting the code and debugging . I am sorry I dont have a quick answer to this right away - but something I would definitely look into and fixing soon.

No problem, I definitely appreciate your feedback/help. It seems like there's some interoperability issues concerning Remote SSH and DartJS, but I am confident you will be able to resolve them! :)

If there's any way I can be of more help via Discord/Slack conversations, maybe we can resolve this together? Bare in mind, I consider myself a novice programmer, so I can be helpful at beta/alpha testing and providing feedback. Let me know.

Thanks.

[akkumar]

" It seems like there's some interoperability issues concerning Remote SSH and DartJS, .. "

For what it is worth - I can share a bit on the internals of what the plugin is doing so it can help us further to pin down the problem.

The source code of this plugin is spread across 2 repositories - dartsass-plugin-common and vscode-plugin ( the current repository - where the issue has been logged and rightly , so ) .

The former does almost all the heavy lifting of the work done by the plugin while this repository
barely contains some vscode api compatible code and delegates it to the former.

Specifically - this problem can be pinned down to what is happening in dartsass-plugin-common/src/native.ts .

Two specific methods - doCompileDocument and watch - contains some quirkiness related to windows and linux, in the form of isWindows() call. ( isWindows() itself is a one-liner - return os.platform() === "win32" ).

It is easy to see why this is the root cause of the problem and why this is a bad idea , specifically in this case.

The host OS is windows but the platform where the plugin runs ( through a SSH ) is not a windows OS. I can understand why this is a problem - but how and what needs to be done , in the context of "remote ssh" execution is something I am honestly unaware of.

But that is a start towards fixing the problem although at this point the next steps remains unclear - I had to admit

[Neltulz]

Interesting. Thank you for the in depth explanation.

In the mean time, is there a command that I can run that will always compile the same SCSS file, no matter which tab is active? This would help alleviate things, since right now, in order for me to force a recompile, I must switch to the root SCSS file, then run the command that recompiles the current file. It's a bit tedious, so a quick workaround would be sufficient for now.

[akkumar]

I have made some changes to the code and made a release - 0.9.0 .

A new property dartsass.execPlatform has been added. You can try changing that to linux ( as opposed to the default host ) and see if that compiles the same.

Also - set sassBinPath to node_modules/.bin/sass since the exec platform is Linux.

The code is untested - to be frank. I would appreciate some kind of debugging information you see in the console.

If you get any trouble - you can try -

• setting - "dartsass.debug" to be true and
• Invoke ">DartSass: Say Current Version" and
• check the output in "DartJS Sass" console and copy paste what you see ( after removing any personable identity information , of course ).

Thanks for your time.

[akkumar]

In the mean time, is there a command that I can run that will always compile the same SCSS file, no matter which tab is active?

This seems like a very interesting feature request.

In the ideal world, when sass watchers are working - this feature would be redundant as that would do - what you are asking.

But sass watchers are not working in the current scenario of being on a windows host and executing on a Linux platform / host though.

See above, for some kind of change that I had introduced to help fix it - but then again the change is entirely untested - to be frank.

Need to spend more time to debug that further .

[Jes3-a]

I have made some changes to the code and made a release - 0.9.0 .

Updated. :)

A new property dartsass.execPlatform has been added. You can try changing that to linux ( as opposed to the default host ) and see if that compiles the same.

Changed to Linux.

Also - set sassBinPath to node_modules/.bin/sass since the exec platform is Linux.

Done.

DEBUG: Configuration reloaded with {"sassBinPath":"node_modules/.bin/sass","includePath":[],"outputFormat":3,"disableSourceMap":false,"sourceEncoding":"utf-8","nodeExePath":"node.exe","debug":true,"disableCompileOnSave":false,"pauseInterval":3,"enableStartWithUnderscores":true,"disableAutoPrefixer":false,"targetDirectory":"css/user","watchDirectories":["/home/mydomain/public_html/v4/templates/logiopeia/scss/user"],"isWindows":false} and projectRoot and sassbinPath: node_modules/.bin/sass

Checked to make sure the sass exists on the remote server. It does:

The code is untested - to be frank. I would appreciate some kind of debugging information you see in the console.

No problem.

If you get any trouble - you can try setting "dartsass.debug" to be true and Invoke "DartSass: Say Current Version" and check the output in "DartJS Sass" console and copy paste what you see ( after removing any personable identity information , of course ).

Output:

DEBUG: sayVersion with projectRoot /home/mydomain/public_html/v4/templates/logiopeia, doesExecOnWindows: false, sassBinPath: /home/mydomain/public_html/v4/templates/logiopeia/node_modules/.bin/sass

DEBUG: Run: Cwd: /home/mydomain/public_html/v4/templates/logiopeia. Exec: node_modules/.bin/sass --version launched with pid 1655219
1.46.0 compiled with dart2js 2.15.1

I noticed that my website blocks URLs to files with omitted file extensions. In web browser:

Forbidden: You don't have permission to access this resource.

However, renaming it to sass.js allows it to be loaded. Then editing the sass bin path to /node_modules/.bin/sass.js does NOT appear to help anything.

DEBUG: Configuration reloaded with {"sassBinPath":"node_modules/.bin/sass.js","includePath":[],"outputFormat":3,"disableSourceMap":false,"sourceEncoding":"utf-8","nodeExePath":"node.exe","debug":true,"disableCompileOnSave":false,"pauseInterval":3,"enableStartWithUnderscores":true,"disableAutoPrefixer":false,"targetDirectory":"css/user","watchDirectories":["/home/mydomain/public_html/v4/templates/logiopeia/scss/user"],"isWindows":false} and projectRoot and sassbinPath: node_modules/.bin/sass.js

🤷‍♂️

Let me know if I forgot to do anything else, or if you have any other ideas of what to try. Also, sorry for flip flopping github accounts. It was an accident.

In the ideal world, when sass watchers are working - this feature would be redundant as that would do - what you are asking. But sass watchers are not working in the current scenario of being on a windows host and executing on a Linux platform / host though.

Yeah, it makes me question if the way I'm doing this is completely wrong. For years, I have always just edited my website directly. A friend didn't understand why I was editing the website via SSH as that appears to be dangerous. I am just very careful, I make regular backups of the site, and I appear to be good enough not to completely destroy the site while editing it.

So, I have a couple of choices. I could either, do all of my editing on my secondary Linux PC sitting next to me, and the issues might resolve themselves, or I can just work on the site locally, and upload the changes. Both options seem unattractive to me, since I apparently like to live dangerously and I like immediate results/gratification. Should I reevaluate how I do things?

[Jes3-a]

Okay, I have a question.

Example:
If I update a file called _child.scss, it should update the parent file that references it called parent.scss.... correct?

If so, then it appears as though that is not working, even when I install your extension locally and I get the Sass watcher working on a completely local folder.

Actual implementation:

DEBUG: Configuration reloaded with {"sassBinPath":"","includePath":[],"outputFormat":3,"disableSourceMap":false,"sourceEncoding":"utf-8","nodeExePath":"node.exe","debug":true,"disableCompileOnSave":false,"pauseInterval":3,"enableStartWithUnderscores":false,"disableAutoPrefixer":false,"targetDirectory":"css/user","watchDirectories":["f:\\_Dropbox\\Dropbox\\_Web\\__MyWebsite\\_Dev\\logiopeia_template_test\\logiopeia\\scss\\user"],"isWindows":true} and projectRoot and sassbinPath: node_modules\sass\sass.js
DEBUG: Unwatching f:\_Dropbox\Dropbox\_Web\__MyWebsite\_Dev\logiopeia_template_test\logiopeia\scss\user with pid 29756
DEBUG: Watching f:\_Dropbox\Dropbox\_Web\_MyWebsite\_Dev\logiopeia_template_test\logiopeia\scss\user.
DEBUG: RunDetached: Cwd: . Exec: node.exe node_modules\sass\sass.js --style compressed --watch f:\_Dropbox\Dropbox\_Web\__MyWebsite\_Dev\logiopeia_template_test\logiopeia\scss\user:css/user
DEBUG: Detached process node.exe launched with pid 28004
DEBUG: 128

It appears as if it's not recompiling the lc.scss file at all. If I edit the _buttons.scss file, it should recompile the lc.scss file, correct?

I have also tried enabling this:

Dartsass: Enable Start With Underscores
Enables compilation of scss files that starts with underscores. By default, false.

But all that does is compile the _buttons.scss file, it does not compile the lc.scss file.

Any information on this would be useful. I'm just very confused right now about what DartJS is supposed to be doing.

[akkumar]

Yeah, it makes me question if the way I'm doing this is completely wrong. For years, I have always just edited my website directly. A friend didn't understand why I was editing the website via SSH as that appears to be dangerous. I am just very careful, I make regular backups of the site, and I appear to be good enough not to completely destroy the site while editing it.

So, I have a couple of choices. I could either, do all of my editing on my secondary Linux PC sitting next to me, and the issues might resolve themselves, or I can just work on the site locally, and upload the changes. Both options seem unattractive to me, since I apparently like to live dangerously and I like immediate results/gratification. Should I reevaluate how I do things?

So - it is easy to see the benefits of instant gratification / results .

But in my experience - it always pays to invest some time in setting up your dev environment locally and work on the same.

But If you do not want to do so and still would like to edit the files directly fully aware of the consequences, you can use WSL ( windows subsytem for linux ) and run vscode in that linux virtual machine (logging in remotely etc). This will solve the incompatibility issue between a different host OS and a guest OS.

[akkumar]

'm just very confused right now about what DartJS is supposed to be doing.

So a brief history , DartJS Sass Plugin was originally developed since I wanted to use the latest and the greatest of sass compiler (dart js implementation ) in my projects.

Over a period of time - the scope of it included the case where if you edit an included file ( say _buttons.scss in the case you mentioned above ) - you also wanted to automatically compile lc.scss that includes the said _buttons.scss as well.

Hence implemented sass watchers for that purpose - so if you edit any file in a particular directory - the sass watcher ensures that the parent files are also compiled automatically. The plugin does not do anything fancy but just delegates the same to the sass cmd line watcher. sass --watch inputdir: outputdir etc.

[Jes3-a]

But in my experience - it always pays to invest some time in setting up your dev environment locally and work on the same.

Understood. I definitely can see why working locally and uploading the changes can be beneficial. It's something I should investigate, since if my site becomes a bustling attraction, making changes to the site while there are visitors could cause disruptions for people. Good advice.

Hence implemented sass watchers for that purpose - so if you edit any file in a particular directory - the sass watcher ensures that the parent files are also compiled automatically. The plugin does not do anything fancy but just delegates the same to the sass cmd line watcher. sass --watch inputdir: outputdir etc.

Gotcha. It's beginning to make sense now.

I experimented with an extension called "Run on Save". This is what I cooked up:

{
    "emeraldwalk.runonsave": {
        "commands": [
            {
                "match": "./scss/user/.*.scss",
                "cmd": "./node_modules/.bin/sass  ./scss/user/lc.scss ./css/user/lc.min.css --style compressed"
            }
        ]
    }
}

Essentially, it does what Sass --watch cannot. Sass is unable to output to a .min.css which seems like a really dumb limitation. People on stack overflow are complaining about this and the accepted answer is that it must be done in 2 separate commands. When watching a directory of child SCSS files, Sass must first compile the parent SCSS file to a .CSS file. Afterwards, you must run a separate command to rename it to yourparentfile.min.css.

My little "Run on Save`` command seems to achieve this in 1 command, which is a serious head scratcher.

This also means, that I practically do not need DartJS Sass Compiler anymore, since it's like using a sledgehammer to break an egg (a malfunctioning sledgehammer - no offense to you, I totally understand that I'm going about things in a very unusual manner, so the fault is entirely mine and I accept that 🙂).

I appreciate all of your help regarding this, but for now, this seems to solve my problem, so I'm going to charge ahead with development. Let me know if you'd like me to test any future versions of DartJS Sass Compiler! 🙂

[akkumar]

I am happy that you were able to find a solution to your usecase.

I certainly understand that the plugin is not perfect in that sense but the use case of being on a windows box while remotely editing files on linux seems very unique but something I as a plugin writer did not foresee.

At some point I will try to dig deeper to see if there is a solution to the same. And I will keep you posted here. But it is not going to be before at least a couple of weeks at least.

Happy coding !