Need help understand tauri "resource" word uses in docs

[PTPhongKMF]

For the tauri team, do you guy considered "resource folder" as the folder that holding the .exe?

Because at first, i always thought when you guy mentioned "resource folder" or "$RESOURCE" in the docs, you guy meant the resource folders that i have defined in tauri.conf.json:

"resources": {
      "../externals/": "data",
      "../externals2/": "data2"
    }

so whenever you guy mentioned restriction or scope about "resource" folders, i imagined it will only applied to D:\...\data and D:\...\data2 for example.

But recently when i use resourceDir(), i noticed that instead of return an array of defined resource path ["D:\...\data", "D:\...\data2"], it return the folder path that hold the .exe . This REALLY CONFUSED me.

So is resourceDir basically executable dir? And any "resource folder" mentioned in the docs meant the whole folder contains the .exe and all subfolders, files; instead of only the folders defined in tauri.conf.json?
If that the case, i would really recommend to use the word "executable folder" in docs about resource folder, as it really more familiar and easier to understand than the term "resource", imo

(what baffled is in past few days, i thought tauri path api didnt have any function to return the executable dir, which is ridiculous. So i have to blindly copy-paste a chatgpt rust code just to get it, turn out it is resourceDir() ?!!!)

[FabianLars]

The exact location of the resource dir is more of an implementation detail that may change without notice.

It's also only on Windows where the resource dir is the exe location.

[PTPhongKMF]

wait, so tauri path api really doesn't have any function to return the exe dir? Is there any reason for that? security concern,...?
I imagined this is really needed for any portable app dev?

[FabianLars]

correct, there is none. Portable apps aren't exactly supported at the moment so the api is more focused on installer based distribution. Getting the installation dir directly isn't exactly useful and not providing a function for this prevented many issues in the past (eg not being able to write into read-only dirs).
Since i'm not that active in support anymore i don't care if people shoot themselves in the foot though so i wouldn't mind if a function for this was added with proper documentation.