Scout-app: Cannot read property 'split' of undefined

The error is coming from trying to act upon the data that comes back from reading your file when no data is coming back. This is something that I can improve, but ultimately that's just handling the error state better. It isn't going to help with your real issue, which is the file not being found.

I don't know why it is having issues finding the file sometimes and not others. My guess is that it is related to "Atomic saves". You could try stopping a project, changing the value of the slider in the settings, then starting it again.

Without being able to reproduce this I don't know why it's happening. I will mark this as a bug though, just so we can better handle error states.

Hi.

I have the same issue only using Visual Studio, but when using Notepad++ or other editor, it compiles correctly.

When i stop and run the project, it always compile correctly in any editor.

Tried to set the "Atomic saves delay" to any value, it wont solve the issue.

Didint look any further in the code, but just placing a setTimeout on App.js _processInputFolder_ function (line 61) will solve my issue.
Yet i know this is not a solution, but maybe the issue is regarding a small delay on saving a file on Visual Studio.

Using:
Windows 10 Pro 64bit
Visual Studio 1.38.1
XAMPP (the server files are served locally)

function processInputFolder (project, inputSubFolder) {


        setTimeout(function() {
            var inputFolder = project.inputFolder;

            if (inputSubFolder) {
                inputFolder = path.join(project.inputFolder, inputSubFolder);
            }
            // Grab all the files in the input folder and put them in an array
            ugui.helpers.readAFolder(inputFolder, function (contents) {
                // check each file and process it if it is sass or scss and doesn't start with an underscore
                for (var i = 0; i < contents.length; i++) {
                    var folder = contents[i].isFolder;
                    var currentName = contents[i].name;
                    if (folder) {
                        var subfolder = currentName;
                        if (inputSubFolder) {
                            subfolder = path.join(inputSubFolder, currentName);
                        }
                        processInputFolder(project, subfolder);
                    // Skip all files that begin with an _ and Process all sass/scss files
                    } else if (!currentName.startsWith('_') && (currentName.toLowerCase().endsWith('.sass') || currentName.toLowerCase().endsWith('.scss'))) {
                        // Change from 'some-file.scss' to 'some-file'
                        var fileName = currentName.slice(0, -5);
                        // Change from 'some-file.scss' to '.scss'
                        var extension = currentName.substring(currentName.length - 5, currentName.length);
                        // send to be converted to css and spit out into the output folder
                        convertToCSS(project, fileName, extension, inputSubFolder);
                    }
                }
            });
        }, 100);
    }

Weird. Since I can't reproduce this I have no means to experiment with it, but I'm curious if this fix comes from the JS event loop and even setting a time out of 0 would still work, or if it is just part of the OS claiming a file is done being accessed earlier than it actually is. If it is the second then 100ms will alleviate the issue for most, but not all, or not in every case, since it would depend on hardware and system resources as to the amount of time it takes for a file to become accessible again.

Either way, binding the timeout duration to match the atomic slider would work, as it would always have a minimum delay of 0ms to cause the event loop to cycle, but could allow setting a 700 ms delay for those on slower machines.

Same happens to me. Stopping and starting the watcher is the only way to process the sass.

Visual Studio Code: v1.38.1 (b37e54c98e1a74ba89e03073e5a3761284e3ffb0)
Operating System: Windows 10.0.18362 x64

This is happening for me now too. When I start a project, it compiles fine, but then when I make changes after that it gives me an error in Dev Tools: "Uncaught TypeError: Cannot read property 'split' of undefined". If I stop it, then start again, it processes changes, but then gives the error again unless stopped. Happening across all my projects. I'm using Atom 1.42.0 on Windows 10.

Was finally able to reproduce the issue consistently. I've added in some better safety checking and a helpful warning message to clue people into bumping up their atomic save delay setting if they are encountering this (to hopefully reduce the amount of GitHub issues created around it).

This has been merged to master and will be in the next release of Scout-App.

Will there be a on-off toggle all together? @TheJaredWilcurt

No, there is a slider that takes the delay from 0 to 700ms. So "0ms" delay would be "off".

First of all Thanks a lot for this App I do love it ;).
I used to work with Atom and it does work like a charm. Recently I used Visual studio code and got the same error.
So maybe the issue is still not solved btw I am using Scout-App V2.18.16 .

Same Error same error Log . It works after I modified scout-files/_scripts/app.js and added a timout for that processInputFolder like @tiagoagre suggested.
Regards

The fix is in master, there has not been a release with the fix in it yet. You can run code from the master branch if this is blocking you, for now.

• https://github.com/scout-app/scout-app/blob/master/documentation/contributing.md#running-scout-app-locally-for-development

Hi @TheJaredWilcurt Thank you very much for your reply. Everything working out after adding a timout for that processInputFolder, but sometimes you need to save the file 2 times to compile( which is not a big problem - maybe I need to play with that timout val!!).
Yeah I am looking forward to your next release, hope to see the fix integrated to it.
Regards