You should be using Application.app_dir(:app_name, "priv/dir/…") in your code to reference files in priv/ folder. You can use configuration for the second parameter if needed.

Additionally you can use the :code.priv_dir/1 function

https://www.erlang.org/doc/man/code.html#priv_dir-1

FWIW these days I register these release-resiliant path concerns in my application’s compile-time config.exs. I find it to be more reliable and easier to reason about if I do it myself:

# config/config.exs
import Config

root_dir = Path.expand("../..", __DIR__)
priv_dir = Path.expand(Path.join(project_root, "priv"))
assets_dir = Path.expand(Path.join(project_root, "assets"))
static_dir = Path.expand(Path.join(priv_dir, "static"))
static_assets_dir = Path.expand(Path.join(static_dir, "assets"))

config :project, :root_dir, root_dir
config :project, :priv_dir, priv_dir
config :project, :assets_dir, assets_dir
config :project, :static_dir, static_dir
config :project, :static_assets_dir, static_assets_dir

# Use variables above to configure things like `:esbuild` in this file

# Use `Application.compile_env!(:project, :static_assets_dir)`
# to configure things like `Plug.Static`

This works well for umbrella apps, since the each have their own config :app_name space.

For often-referenced paths, I’ll even add a shortcut in my project’s main entrypoint module:

# lib/project/application.ex
defmodule Project.Application do
  def app_name, do: :project
  def root_dir, do: Application.compile_env!(app_name(), :root_dir)
  def static_dir, do: Path.relative_to(Application.compile_env!(app_name(), :static_dir), root_dir())
end

Then, for example, configuring Plug.Static can look like:

# lib/project_web/endpoint.ex
plug Plug.Static,
  at: "/",
  from: {Project.Application.name(), Project.Application.static_dir()}

Tbh that feels a bit bend over backwards to start with relative paths, expand them to absolute paths for the context of the mix project, just to turn them back into relative paths within the application code again. But I do like the approach of having functions return the paths. I’ve used that approach as well in some projects. It puts a clear interface of what paths are provided by an application / which ones are used by downstream consumers.

I am generally not comfortable having functions that return configuration settings.

To me, configurations are different from the functionality an application offers, they are a prerequisite and should therefore have their own space, instead of polluting the main API that I expose to the public.

Still, if nothing else works, I will definitely use such approaches, I find code that actually does something better than code that is theoretically more perfect, but then does nothing

Also, thanks @christhekeele for your input. I appreciate you took the time to read all the threads and then took even more time to add your own opinion, even though the topic is becoming long and I had marked it as solved.