feat(app): configurable Modrinth endpoints through .env files

[AlexTMjugador]

Overview

These changes make the API and website endpoints used by the Modrinth app to referring to Modrinth services configurable through a .env file located at packages/app-lib, which is read at compile time. This brings the app environment configuration method in line with that used by the frontend and Labrinth.

As a result, developers can easily test any combination of Labrinth backend and frontend directly from the app without modifying any source code. Additionally, build workflows now clearly have to define which environment the app is using, allowing them to select the staging environment when appropriate.

⚠️ Important change for other app developers

After this PR is merged, a .env file must be present at packages/app-lib with the appropriate variables in order to build the app. You can initialize a suitable .env file with a command like cp packages/app-lib/.env.prod packages/app-lib/.env.

[Gaming32]

Rather than getting rid of this file entirely, why not use it to read the environment variables? That way the environment variable names aren't hardcoded in several spots throughout the codebase.

[AlexTMjugador]

I personally don't see much difference between importing a constant from a module and using the env! macro. In both cases the string is set by the compiler at build time, and a compiler error happens if it is missing. You still have to name the variable you're referring to anyway, so it's not like it's less hardcoded. Having a config.rs file in addition to .env is unnecessary boilerplate in my opinion.

Edit: a side benefit of env! is that it works well in combination with the concat! macro for compile-time string concatenation, as env! expands to a string literal, not a constant reference.

[Gaming32]

I'm primarily thinking of MODRINTH_API_URL, MODRINTH_API_URL_V3, and MODRINTH_LAUNCHER_META_URL, which are used multiple times (14, 6, and 2, respectively). So if these variable names are changed, or if someone needs to access one, they have little IDE help, which reduces maintainability.

[AlexTMjugador]

In those cases, I usually fall back on the good old Ctrl + Shift + F (or the equivalent shortcut in your favorite IDE) to search for and replace text in all files. Code-aware refactoring tools in IDEs can be helpful, but they're not always reliable anyway, especially when conditionally compiled code is involved. Personally, I don't see much difference between doing a mass search-and-replace like this or through a refactoring tool in this case.