Improvement to Import and compile - Purging classes not on disk

[jpa95]

Hi,

a recurring annoyance is when switching branches and compiled classes from the old branch remain in the namespace sometimes creating compilation errors.

Scenario:

1. I am working on branch X, I have added class C, it is installed into the namespace
2. Using Git, switch to branch Y. This branch does not have the file for class C yet.
3. Import and Compile to sync disk into namespace

Result:
If the dependencies of class C are no longer met, we will see a compilation error in the log. If the dependencies are met there will be no error, but we will still have a "zombie" class in our namespace. This may or may not affect the stability of the namespace.

Workaround has always been to delete zombie files by hand in the namespace.

Request:
Ideally the Import+Compile could purge the classes that no longer have an equivalent on disk. A manual purge command would also be acceptable, before or after the Import+Compile. N.B. We are using client-side editing.

[isc-bsaviano]

@jpa95 I think this will be covered by #1401. I need to update that branch and address a few bugs/features, but I plan to have that released this year.

EDIT: Here's what I still need to do: https://community.intersystems.com/post/do-you-use-client-side-editing-vs-code-if-so-we-want-your-feedback#comment-270941

[GendronAC]

I would really love this feature, but I can see how it might be challenging when working with VSCode multi-root workspaces, since a class could exist in any of the repositories

[isc-bsaviano]

@GendronAC Yeah, if you have multiple local workspace folders connected to the same server namespace (whether they're in a single workspace or even the same machine) you can get into trouble. That's why you should be using a "throwaway" instance/namespace if you're doing client-side editing. You should be treating IRIS as a SDK that's only there for compilation and intellisense and not worry about the state of the server beyond the syncing of the files you're editing.

[jpa95]

@isc-bsaviano On reading #1401 i'm not 100% sure I can say with confidence that this will be covered, but my educated guess is that the FileSystemWatcher functionality would catch these changes on git pull?

Anywho, I'll post feedback in the community. Thanks for the quick reply!

[isc-bsaviano]

@jpa95 I believe your request is for this:

Delete a file on the server if the last Uri for it in a workspace folder was deleted.

That already exists in the PR, but there's more work to de before changing a git branch would automatically sync all classes and routines. Note that this feature is only for classes and routines at this point.

[jpa95]

@GendronAC Yeah, if you have multiple local workspace folders connected to the same server namespace (whether they're in a single workspace or even the same machine) you can get into trouble. That's why you should be using a "throwaway" instance/namespace if you're doing client-side editing. You should be treating IRIS as a SDK that's only there for compilation and intellisense and not worry about the state of the server beyond the syncing of the files you're editing.

We do our development locally on our machine (my machine is the namespace server) so i guess that would count as a throwaway environment.

[jpa95]

@isc-bsaviano I think #1401 covers this then, I will close.