nickdodd79 / vscode-gulptasks

A gulp task visualization and execution extension for Visual Studio Code
MIT License
7 stars 6 forks source link

Error: spawn sass.bat ENOENT #27

Closed kAlvaro closed 5 years ago

kAlvaro commented 5 years ago

I have a task to run the Ruby version of SASS on Windows:

const gulp = require('gulp');
const child_process = require('child_process');

gulp.task('css', function (cb) {
    child_process.execFile('sass.bat', [
        '--sourcemap=none',
        '--no-cache',
        '--style=compressed',
        'foo.scss',
        'foo.css'
    ], {
        cwd: 'webroot/styles'
    }, function (err, stdout, stderr) {
        cb(err);
    });
})

I works correctly in command line (tested both in CMD and PowerShell):

gulp css

However, when I run the task with the extension I get:

> css: STARTED
> css: Using gulpfile d:\Projects\Foo\src\gulpfile.js
> css: Starting 'css'...
> css: 'css' errored after 5.17 ms
> css: FAILED
> css: Error: spawn sass.bat ENOENT
> css: at _errnoException (util.js:1022:11)
> css: at Process.ChildProcess._handle.onexit (internal/child_process.js:190:19)
> css: at onErrorNT (internal/child_process.js:372:16)
> css: at _combinedTickCallback (internal/process/next_tick.js:138:11)
> css: at process._tickCallback (internal/process/next_tick.js:180:9)

I thought it might be having issues finding sass.bat through the PATH environment variable but using an absolute path ('D:\\Ruby22-x64\\bin\\sass.bat') just triggers Error: spawn D:\Ruby22-x64\bin\sass.bat ENOENT.

:-?

nickdodd79 commented 5 years ago

Hey @kAlvaro

I'll take a look and see if I can work out why. Watch this space.

Nick.

nickdodd79 commented 5 years ago

Hi @kAlvaro

Finally got some time to look at your issue. It would seem the setup of your child process is causing the failure. To start with I couldn't get it run via the extension or directly in the console.

I managed to get your code to run when everything is defined as absolute paths as below (I removed some of the process flags for verbosity).

const gulp = require('gulp');
const child_process = require('child_process');

gulp.task('css', function (cb) {
  child_process.exec(
    'C:\\Ruby-x64\\bin\\sass.bat test.scss test.css', 
    {
      cwd: 'C:\\project\\webroot\\styles'
    }, 
    function (err, stdout, stderr) {
      cb(err);
    });
})

It would seem that it was either trying to resolve sass from the styles path or trying to find the test.scss in the ruby bin.

nickdodd79 commented 5 years ago

Closing due to no follow up.

kAlvaro commented 5 years ago

My excuses, I hadn't understood you were expecting further feedback from me. Do you want me to try replacing child_process.execFile with child_process.exec and using full path to sass.bat? If so, I'll be able to report back on Monday.

In any case my current gulpfile.js works for me in the console (either standalone or from within VSCode). I must note that I have D:\Ruby22-x64\bin in my system's PATH.

kAlvaro commented 5 years ago

I'm possibly doing something wrong but I can't make it work either with child_process.exec and full path to sass.bat. I get a similar error, just with a different file in spawn ENOENT:

> css-test: STARTED
> css-test: Using gulpfile d:\Projects\Foo\src\gulpfile.js
> css-test: Starting 'css-test'...
> css-test: 'css-test' errored after 4.09 ms
> css-test: FAILED
> css-test: Error: spawn C:\WINDOWS\system32\cmd.exe ENOENT
> css-test: at _errnoException (util.js:1022:11)
> css-test: at Process.ChildProcess._handle.onexit (internal/child_process.js:190:19)
> css-test: at onErrorNT (internal/child_process.js:372:16)
> css-test: at _combinedTickCallback (internal/process/next_tick.js:138:11)
> css-test: at process._tickCallback (internal/process/next_tick.js:180:9)
gulp.task('css-test', function (cb) {
    child_process.exec('D:\\Ruby22-x64\\bin\\sass.bat --sourcemap=none --no-cache --style=compressed foo.scss foo.css', {
        cwd: 'webroot/styles'
    }, function (err, stdout, stderr) {
        cb(err);
    });
});

As with the original task, it works fine from a regular prompt. (I only opted for execFile because I can pass arguments in an array and I don't need to escape them.)

Is there any check I can do for you?

nickdodd79 commented 5 years ago

I will need to take another look just to refresh my memory on the issue. Can you try adding the sourcemap and other flags along side the cwd property (i.e. in the object).

kAlvaro commented 5 years ago

I've tried several variations of what I understood you're referring to:

{
    cwd: 'webroot/styles',
    "--sourcemap=none": "",
    '--style=compressed': "",
    'foo.scss': "",
    'foo.css': ""
}
{
    cwd: 'webroot/styles',
    "--sourcemap": "none",
    '--style': "compressed",
    'foo.scss': "",
    'foo.css': ""
}

... and some more but I only get even more cryptic errors messages:


Also, I've set up the complete stack in another computer. I've just discovered that Ruby Sass is abandoned so I've used Dart Sass this time. And it works flawlessly (apart from having different switches, so --sourcemap=none and --no-cache need to go), despite also being a *.bat file to be found in PATH.

I can't get back to the other PC (the one with Ruby) until Monday. I'll try Dart Sass there. I'm curious to find out what changes. Honestly, if the problem doesn't show up then, I reckon we could just happily ignore it.

kAlvaro commented 5 years ago

I can confirm that Dart Sass works flawlessly in my other PC too.

Whatever the problem is, I feel it isn't the extension's fault.

nickdodd79 commented 5 years ago

Hey @kAlvaro

Firstly apologies for no follow up on my side - I've been a little time poor recently.

Thanks for the confirmation. As you say, it does look like something going on with Ruby Sass that is causing the problems. From memory, my findings was that is was attempting to resolve paths from some relative root that was not common between the sass.bat file and the styles folder.

If you are happy with the result, can this issue be closed?

Thanks, Nick.

kAlvaro commented 5 years ago

The only difference I've been able to spot between running gulp from command-line and from your extension is that the %CD% env variable as read within sass.bat gets different case for drive letter:

Unless something in that strikes as immediately obvious to you, I'm fine with closing the ticket.

nickdodd79 commented 5 years ago

Hey @kAlvaro

The extension requests the env variables from the node process and are used as provided. This to me implies node is altering the casing of the value.

One option would be add a config item that allows key/values to be defined that are appended to the gulp processes. Therefore, you could override the %CD% value with whatever you needed it to be.

Nick.

kAlvaro commented 5 years ago

I don't think I fully understand your proposal but, considering that the only use case so far would be a deprecated tool that already has a supported replacement, I'd vote to not do that.

(I'm closing the ticket, I hope there's no problem.)

nickdodd79 commented 5 years ago

Fine with me. I think where we have arrived with this issue works well. Thanks.