fix: Always prefer tauri configs further up the file tree

[FabianLars]

This fixes issues where the action used config files in deeply nested directories instead of the correct one in the upper levels.

ref: https://discord.com/channels/616186924390023171/1119317689836515388

kinda quick and dirty, have to call it a day. If it works for the user in that thread too i'll try to clean it up a bit. (or maybe not as i don't want to have a helper function just to reuse that inner for loop)

Edit: User confirmed it worked for them, therefore converting it to a normal PR, still gonna plan to try to clean it up a bit but feel free to have a look.

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Packages	Version	New capabilities	Transitives	Size	Publisher
globby	13.2.2	None	+2	126 kB	sindresorhus

🚮 Removed packages: glob-gitignore@1.0.14

[FabianLars]

okay nevermind about cleaning it up, i'd rather keep it as simple&stupid as possible for now.

[amrbashir]

Looking at the code, it seems that this is only traversing down and not up, right? if so I fail to see how is this different from the previous impl

[FabianLars]

take for example this file tree, taken from https://github.com/tonymushah/special-eureka/tree/master/src-tauri:

/
  src-tauri/
    examples/
      tauri.conf.json
    src/
    tauri.conf.json # this is the file we want

The current implementation will always select src-tauri/examples/tauri.conf.json while the new one will go for src-tauri/tauri.conf.json -> tested by me and confirmed by 2 community members one of which linked above.

One variant i didn't think about would be this

/
  src/
  some-package/
    whatever/
      tauri.conf.json
  src-tauri/
    tauri.conf.json # this is the file we want

Here the new implementation will also go for the wrong file. I can't remember if setting projectPath to the src-tauri dir and not its parent works too so that would need some testing too ig

[amrbashir]

I see but as you outlined this fix is not complete as it doesn't account for levels at all, I'd recommend reverting this change and use glob again but instead of taking the first result, we sort the return paths first by how far are they to the current working directory.

[FabianLars]

Do you have any pointers on how to sort them then? Because i didn't find an easy-ish & reliable way to do that which is really why this PR exists in the first place.

[amrbashir]

if we are looking down only, then it should be easy to just split on path separator and count the components of the path, and choose the lowest number

[FabianLars]

yeah, that sounded kinda scary in my head but if you also have that in mind we can try it out and keep an eye on it, thanks 👍

[FabianLars]

I found an old todo entry to evaluate globby since it can handle gitignore files dynamically (i mean it adds gitignore files along the way, not just the ones we give it upfront) so i switched to that. And apparently it already sorts the results correctly in contrast to really all the other glob/file search packages i tried 🥳

I'll keep an eye on it though and re-add the sort() call if necessary.