[feat] replace unmaintained dirs_next crate

[JonasKruckenberg]

Describe the problem

The dirs_next crate used in the tauri::api::path module is unmaintained since 2021-ish see here and here.

Describe the solution you'd like

Replace dirs_next with directories. This has the added benefit that directories::ProjectDirs creates proper app-scoped paths for each supported OS. Example:

Our current dirs_next implementation returns {FOLDERID_RoamingAppData}\{bundleIdentifier} from app_dir() while directories::ProjectDirs::app_data() returns the proper {FOLDERID_RoamingAppData}\{Organization}\{ProductName}\data.

directories also enforces proper paths through ProjectDirs constructor.

HOWEVER: This would introduce a breaking change, as paths returned by directories are not the same as paths returned from dirs_next.

Alternatives considered

There are a number of alternatives to dirs_next, but all seem to recommend directories in the end.

Additional context

This is closely related with #6062 which would also introduce a breaking change.

[FabianLars]

We talked about this some weeks or months ago and concluded that it's not worth switching because the alternatives are not much more maintained either.
I'll dig out the convo when I'm home but we basically said to stick to dirs-next unless there's actually a reason to switch like it being broken or other crates having apis we need.

[JonasKruckenberg]

unless there's actually a reason to switch like it being broken or other crates having apis we need.

Yeah I remember, so basically my point is that directories produces more correct and better looking paths especially on Windows.

Edit: Oh and that we can upstream Android support to directories while dirs-next doesn't support Android and being unmaintained likely never will

[FabianLars]

So it's not about the "next" and non-next crates, but dirs vs directories which i guess is fair but could be fixed by us by just not using the bundle id in the appDir functions.

(Or are there other diffs between next and non-next in the paths in general like when comparing the "same" functions between crates? Can't compare them on my phone)

[JonasKruckenberg]

Or are there other diffs between next and non-next in the paths in general like when comparing the "same" functions between crates? Can't compare them on my phone

Yeah, so I just double checked and it seems that both crates return the same paths for all other functions, the only difference is in the app-scoped directories.

Edit: To be fair we don't need to use directories::ProjectDirs::from and have the breaking change suggested in #6062 but directories::ProjectDirs::from_path with the bundleId which would be closer to the dirs_next API, but still be a breaking change (on win a few paths like the app_cache_dir would change from {FOLDERID_LocalAppData}\{bundleId} to {FOLDERID_LocalAppData}\{bundleId}\cache)

But the big advantage would be that we could finally add Android support. especially app_data_dir is used by many apps and not having support for android breaks a whole bunch of things (like the tauri-plugin-store see here #6054)

[JonasKruckenberg]

I decided that we can keep the Android implementation of the paths module in-tree for now, see #6068. We can decide on changing the crate used (and the way we construct the app dir) for v2

[amrbashir]

I am fine with moving back to dirs crate which should be the same as dirs-next API so no breaking changes are needed. Also note that directories crate is the mid-level sister of dirs crate of the same org.

[amrbashir]

but if you really want to use the lower level directories crate I am fine with that too as long as it is implemented along #6062 (if we decide #6062 is gonna be implemented)

[FabianLars]

Here's the discussion i was talking about in my first comment: https://discord.com/channels/616186924390023171/807549941936816148/1039492950075379713 / tauri-apps/tao#615 (comment) which was about dirs vs dirs-next