Editing in Visual Studio and watch does not work.

[rippo]

trafficstars

I have a weird problem where if I use Visual Studio to edit my ts files the watch does not see the file changes. If I use say Notepad++ and edit a ts file the watch kicks in and compiles the changes.

This is my gruntfile:-

module.exports = function (grunt) {
    "use strict";
    grunt.initConfig({

        ts: {
            options: {
                sourcemap: true
            },
            build: {
                src: ['GruntTesting/Scripts/ts/**/*.ts'],
                //outDir: 'GruntTesting/app',
                out: 'GruntTesting/app/site.js',
                watch: 'GruntTesting/Scripts/ts'
            }
        }
    });

    grunt.loadNpmTasks("grunt-ts");
    grunt.registerTask("default", ["ts:build"]);

};

When editing in Visual Studio I get this (does not work):-

When editing in Notepad++ I get this (does work):

Maybe its some setting in VS I need or some other oddity, can anyone shed light on this?

[basarat]

If I use say Notepad++ and edit a ts file the watch kicks in and compiles the changes

We have noticed this. When this happens, if you actually open the file on the file system you will notice it doesn't contain your changes. This was happening in VS 2012 for us.

Also for many of us VS 2013 is failing to reload the file from the file system once it changes externally (e.g. by transformers).

Nothing we can do about it. If you wait a bit (like 5 seconds) VS does buffer the changes to disk. And for loading the external changes into VS closing and reopening the file tends to help (sadly)

[nycdotnet]

Is this a Visual Studio bug? I've never observed this with other file types in VS. (I can't recall ever having observed it with TypeScript either, though.)

[rippo]

Sorry but I don't see this behaviour at all.

I have test1.ts open in both VS and Notepad++ at the same time and I modify the file in VS2013 the changes are picked up straight away in Notepad++. Grunt still sits there so something is amiss.

[basarat]

Also for many of us VS 2013 is failing to reload the file from the file system once it changes externally (e.g. by transformers).

@nycdotnet :

[basarat]

Grunt still sits there so something is amiss.

@rippo Just curious, are you running VS as "Administrator"? (perhaps you have it setup automatically for something like IIS debugging).

PS: This stopped happening for us when we moved to 2013 for some reason.

[rippo]

@basarat

Just curious, are you running VS as "Administrator"?

No running as normal. All other editors like sublime, webstorm pick up the fact that that needs to be reloaded when I save in VS. Its only grunt that doesn't pick this up.

[basarat]

Its only grunt that doesn't pick this up.

you can put a console.log(arguments) here : https://github.com/grunt-ts/grunt-ts/blob/master/tasks/ts.js#L387 i.e.

function handleFileEvent(filepath, displaystr, addedOrChanged) {
                    console.log(arguments);
                    if (typeof addedOrChanged === "undefined") { addedOrChanged = false; }

to help us know if it is something in our code or 'chokidar'. I do appreciate your time. Sorry that I cannot reproduce it reliably.

[rippo]

Hi thanks for your effort going into this, this is what I see in console when I change a ts file in VS:-

So it looks like it is picking something up, its just not changing the JS file in GruntTesting/app/site.js . Strange

[basarat]

oh oh. This means we have a bug in our code. Sorry. Can you uncomment this https://github.com/grunt-ts/grunt-ts/blob/master/tasks/ts.js#L395-L399 to see if we are ignoring it by any chance i.e. final code

                    // Do not run if just ran, behaviour same as grunt-watch
                    // These are the files our run modified
                    if ((new Date().getTime() - lastCompile) <= 100) {
                        // Uncomment for debugging which files were ignored
                        grunt.log.writeln((' ///'  + ' >>' + filepath).grey); // !!! Uncomment this 
                        return;
                    }

[rippo]

aha, it works now so it does look like a bug....

[basarat]

So you press Ctrl+S once and we get three events?

[rippo]

Yes this is a single CTRL + S , will double check that statement

Yes tried a few times, always three events. On a SSD drive if that means anything!

[basarat]

I see the bug now. If something where to raise these in a row :

on('change', function (path) {
                    handleFileEvent(path, '### changed ', true);

                    // Reset the time for last compile call
                    lastCompile = new Date().getTime();
                })

and lastCompile gets reset while we are still in handleFileEvent and haven't hit this yet:

// Do not run if just ran, behaviour same as grunt-watch
                    // These are the files our run modified
                    if ((new Date().getTime() - lastCompile) <= 100) {

so lastCompile gets reset externally (by the event handler) and this handleFileEvent aborts as well.

@rippo thanks for your time. We know how to reproduce it (some way to ctrl+s in under 100ms ;)). Sorry my bad. Will fix it when I see a clear solution. PRs appreciated.

[rippo]

Perfect, least I have a way to use grunt now, look forward to a fix :) If you need to run past anything by me I can be your guinea pig. Thanks

[duaned]

Has this issue been resolved? I'm currently experiencing this issue but I've found some work arounds.

I removed the watch from my grunt-ts config and swapped it out for grunt-contrib-watch which seemed to work.

After that I switched back to a grunt-ts watch but with a fresh checkout of my project and it started picking up changes and compiling again.

I also commented out the if statement that checks the last compiled time and it started picking up changes on the offending checkout, but I also noticed it was compiling it 3 to 4 times every time I changed a file.

Preferably don't want to do a fresh checkout every time this starts happening so a fix for this would be appreciated.

[nycdotnet]

Sorry we haven't fixed this yet. That sounds like the behavior that @rippo was experiencing.

@basarat do you think a simple debounce would be good enough to work around this?

[basarat]

do you think a simple debounce would be good enough to work around this?

Probably not. Simple debounce will only call with last change argument. We probably want to call with all changes. That said, considering all the edge cases is out of scope, so feel free to give it a go with a simple debounce :+1: