Fix auto upload

[auxves]

Short description of what this resolves:

This PR fixes auto-upload by using Chokidar and vscode.extensions.onDidChange instead of vscode.FileSystemWatcher, which only works on files in the current workspace.

Changes proposed in this pull request:

• Use Chokidar instead of vscode.FileSystemWatcher to detect changes in user settings
• Use VSC's onDidChange event to check for changes in extensions
• Unlock lock file when returning from the StartWatch() function after locking to prevent it from becoming unusable

Fixes: 3

How Has This Been Tested?

I have tested it by installing/uninstalling extensions and modifying my settings. I can confirm that the changes don't affect any other areas in the code, and it uploads and downloads successfully.

Checklist:

• I have read the contribution guidelines.
• My change requires a change to the documentation and GitHub Wiki.
• I have updated the documentation and Wiki accordingly.

[shanalikhan]

Thanks for the PR.
I will look deeply in few days and accept after testing.

But if you look into this link.
https://code.visualstudio.com/api/references/vscode-api#workspace.createFileSystemWatcher

It says

A glob pattern that is applied to the absolute paths of created, changed, and deleted files. Use a relative pattern to limit events to a certain workspace folder.

I think we still can use vscode watcher itself, if they provide watch on absolute paths. If yes, then we only need to fix the paths.

[shanalikhan]

It was removed on 7716e71#diff-72050d84a8ab08bacc0bd4ac1c1bfb8f by @nekonenene

I think what it means by that is you can watch for a specific folder in your

In 'Workspaces' only or we can set by absolute paths ?

[auxves]

On that same page, it says this:

Note that only files within the current workspace folders can be watched.

Use a relative pattern to limit events to a certain workspace folder.

I'm guessing this means that you can use relative paths to watch a subfolder of a workspace folder, like src or src/utilities, but the rules still apply.

[shanalikhan]

alright, thanks
I will merge this into next version.

[auxves]

This PR has a bug which has been fixed in #814. Please try that one as it not only fixes this bug, but it also adds some great new features.

[shanalikhan]

Can you re-open this and fix this independent so I can publish the new version containing this only this fix alongwith other PR ?

[auxves]

Sure. However, It might take a while since I am going to be away from home for a few days. I'll try to fix it as soon as possible.

[auxves]

I should be able to do it today, but I'm not 100% sure.

[shanalikhan]

No problem, we can wait. Give me a signal to test and publish when you are ready.

[auxves]

These changes should fix it. Please look out for formatting issues in the code as I used my old laptop, and it seems like it messed up the formatting a bit. Other than that, it should work. If it doesn't, just let me know and I can try to fix it when I get back home.

[shanalikhan]

I have reviewed the code.
One thing is must that we need to use async/ await where possible.

[auxves]

Ok, I have reverted to using asynchronous functions, and the code is ready to be further tested.

[shanalikhan]

Thanks. I have added more reviews.

One problem that users were having problem regarding the lock was not working as expected.

You can test the lock by running the following scenarios:

1. Run auto upload, while its processing. Change one observed file and see, does the autoUpload runs again by destroying the old processing state or waits for it to be complete and ignore the again upload call.
2. Open 2 code windows. edit any file and run autoupload from one code window by changing any observed file, while auto upload is running - Change the file once again from the second code window and observe - Acceptance will be it should ignore the auto upload process from the second code window and inform user that its already in process.

Can you please let me know after running the above two test cases.

Other than that, can we add some test cases for autoUpload as well ?

These are the final reviews, once done alongwith tests performed. It will be ready to merge and release with new version :)

[auxves]

Here are the results from my testing

• Run auto upload, while it's processing. Change one observed file and see, does the autoUpload runs again by destroying the old processing state or waits for it to be complete and ignore the again upload call.

Open 2 code windows

I couldn't get two windows open with the development host, but the code still depends on the lock file, so it shouldn't matter how many windows there are open.

[shanalikhan]

I couldn't get two windows open with the development host, but the code still depends on the lock file, so it shouldn't matter how many windows there are open.

You can make package from vsce package of extension.
Install extension on your computer from compiled and run the code on both windows.

[auxves]

Ok, I'll try that as soon as I can and update the results when I'm done.

[auxves]

Ok, I have tested it and can confirm that the lock file works. After starting auto upload on one window, attempting to start it on another window stopped the operation because the lock file was locked.

[shanalikhan]

Thank you for work.
Its merged and will be released in next version
One more question? Are you available for future bug fixes regarding auto uploads?
I can tag you when where there will be any problem

[auxves]

Thanks for merging! And yes, I will be available, just tag me and I'll get to work as soon as possible.

[shanalikhan]

New version is published. :)
Thanks for the PR