Hi @KhanKudo

thank you for your contribution. First look looks good. Nicely isolated. I will try to give a better look in the next week.

Awesome, glad to hear you like it. It would be fantastic to close the feature request. This behavior has been wished for since at least January. Given the large user base of Path-Intellisense, I tried my best to make sure there were no unintended consequences, thus the selector limits use to explicitly .nix files. The implementation however could very well be useful in .sh or other text files where paths are commonly used outside of quoted strings, such as for GitLab/GitHub CI/CD configs.

Hi @KhanKudo

I reviewed and tested your PR. It works as expected and the code is easy to understand. I like how you added it as a separate provider and made sure it doesn't conflict with the existing solution. Thank you for your amazing work 🤩

I noticed that you are reusing the provide from the JavaScript provider. It is almost the same code so I see why it would make sense. My idea with the providers and the util functions was, that the common code is in utils and the providers do not depend on each other. This ensures that single providers can be refactored in the future without me having to worry that I break another provider.

Could you duplicate code? It is a few duplicates line but mostly just calls to utils fns. The file createCompletionItem.ts which is currently in the Javascript provider could be moved into the utils folder. It is not 100% provider agnostic but enough to justify to share it. This way, the providers are completely independent from each other. Would that be good?

Note: the test are not running on Ci. This has nothing to do with your change. I have to check what the issue.

Thank you again for your contribution. Looking forward to merge the first provider next to JS

I absolutely agree, different providers should not depend on each other. I have pushed a new commit that moves createCompletionItem.ts and createContext.ts to the utils folder. And whilst I usually prefer to avoid code duplication at all cost, I definitely have to agree that in this case, it is a lot better to have some duplication but keep independent code separate.
Given that javascript and nix have basically nothing in common, it is certainly a good practice to assume they might have different needs and thus provider differences in the future.

Thank you @KhanKudo for making those changes. Looks very good.

The only thing you missed is to revert the changes in the javascript provider in the provide function. We don't need to export it anymore and have the optional parameter. Could you fix that? After that from my side the Nix support is ready to be published :-)

Oh that's a silly oversight haha.
I'll fix it in just a sec ;)

Thank you @KhanKudo for your contribution. Nice work and pleasant discussion. I will create a new release with your PR. 🚀