Handle symlinks in path

[denizariyan]

What this PR does / why we need it:

Currently it's not possible to use symlinks in a path pattern as the extension doesn't resolve the symlinks. I have a use-case where the build directory in my workspace is a symlink to a build cache which currently results in me not being able to use this extension.

This PR adds a symlink resolution step during the configuration that resolves the symlinks to their real path, allowing one to use symlinks in their path pattern.

Special notes for your reviewer:

I have set some of the new tests that create real symlinks to be skipped on Windows. AFAIK old Windows versions (pre some update of Win10) require Admin privileges to create symlinks, which is required for the tests. I also don't have easy access to a Windows box so I can't test if the tests works on newer versions... The implementation is agnostic since the node filesystem abstracts the differences.

If you prefer so, we can remove the skip and try with the Windows github actions runners, up to you! All maintainers of this repo also have access to the branch on my fork so you can also give it a try or change things if you like.

Question to reviewer:

Would you consider this a new feature or a bugfix? Asking so I can bump the correct version on the changelog.

[matepek]

Hello,
Thank you for your PR. Please work with me on it a bit. I will start reviewing and ask questions and make suggestions.
Then we can iterate on the code.

My first question would be: Why do we ned this feature? Please elaborate on your use case.

• What OS do you use?
• What build system do you use?
• Why the symlinks are created?
• and any relevant information would be helpful..

[denizariyan]

Hello, Thank you for your PR. Please work with me on it a bit. I will start reviewing and ask questions and make suggestions. Then we can iterate on the code.

My first question would be: Why do we ned this feature? Please elaborate on your use case.

• What OS do you use?
• What build system do you use?
• Why the symlinks are created?
• and any relevant information would be helpful..

Hey @matepek, thanks for having a look!

My first question would be: Why do we ned this feature?

Does the PR description answer it or do you have a specific question in mind?

What OS do you use?

Ubuntu Linux

What build system do you use?

Bazel

Why the symlinks are created?

The build directory within the workspace is a symlink to another directory outside of the workspace which is also a Bazel build cache. Having symlinked build output directories are pretty common with Bazel build cache.

[matepek]

Does the #498 (comment) answer it or do you have a specific question in mind?

I asked those specific questions and you answered them, thank you. :)

I'm afraid the problem is a bit complicated. I think we need a research on when those symlinks change.
Just had a quick discussion with an LLM and it seems it is a good start but later on the extension should cover the case when the symlink changes:

• executables probably should be re-discovered and reloaded.

There are some closed bazel related issues. Let me ping the users, maybe they have some input as well.

[matepek]

Okay, checked those issues, I think we can allow one symlink in the path.
Also we should do it in the async way.
Further more we can watch the resolved directory and the symlink itself for changes with FSWatcher.
I have further comments regarding to the code:

• unnecessary comments
• no silent exception

Are you up for an iteration?

[denizariyan]

Thanks for the feedback @matepek! I added a commit (bcb516f) to address the points from this comment.

I also had a go at reloading the executables (or the whole exec group) when the symlink changes as you mentioned but I feel like I am not familiar enough with the codebase to implement this properly. Would you be able to look into that? I think it would be possible by having the resolveSymlinksInPattern return the symlink path and attaching a watcher directly on that but I had some trouble figuring out how to re-load&re-discover everything properly afterwards.

It's also not the most common use-case, at least with the Bazel build cache example I have, so I think it's an option to have this as a further enhancement later. In the end, symlinked paths don't work at all right now so it's not a regression.

[matepek]

Just curious, this is an AI generated code, right?

[denizariyan]

Just curious, this is an AI generated code, right?

Mostly yes.

[matepek]

Then I hope you don't mind I changed a bit more for my taste.
Now handles symlink deletion but not recreation. Not yet.
Please check it out how it works for you.

[denizariyan]

Looks good to me, thanks.

Should we add a changelog entry for a new feature release or do you want to wait until symlink re-creation is also handled? I would prefer to have a new release now if you don't mind.