Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/HectorDNC/galactic-tournament-front/llms.txt

Use this file to discover all available pages before exploring further.

Galactic Tournament uses Angular’s built-in environment file system to manage configuration values — most importantly the backend API base URL — across different build targets. Understanding how these files work is essential before deploying the app or contributing to it locally.

​
How Angular Environment Files Work

Angular supports multiple named build configurations (defined in angular.json). Each configuration can declare fileReplacements — a list of source files to swap out at build time. The app always imports from environment.ts, but the Angular compiler silently replaces that file with the environment-specific version before bundling. The three environment files live in src/app/environments/:
FileUsed when
environment.tsDefault — also the Docker injection target
environment.development.tsng serve --configuration development / pnpm run dev
environment.prod.tsng build / pnpm build (production configuration)
The replacements are configured in angular.json under projects > ng-tailadmin > architect > build > configurations: 
"production": {
  "fileReplacements": [
    {
      "replace": "src/app/environments/environment.ts",
      "with": "src/app/environments/environment.prod.ts"
    }
  ]
},
"development": {
  "fileReplacements": [
    {
      "replace": "src/app/environments/environment.ts",
      "with": "src/app/environments/environment.development.ts"
    }
  ]
}
The serve target’s defaultConfiguration is "development", and the build target’s defaultConfiguration is "production". Running pnpm run dev therefore automatically picks up environment.development.ts, while pnpm build picks up environment.prod.ts.

​
The Environment Files

Each environment file exports a single environment constant. Services import it directly — for example, SpeciesService constructs its base URL as `${environment.api_url}/api/species`. 
export const environment = {
    production: false,
    api_url: 'https://galactic-tournament-app-production.up.railway.app',
};

​
The api_url Field

api_url is the only application-level configuration value in these files. Every HTTP service in the project prepends it to its endpoint path: 
// species.service.ts
private readonly url = `${environment.api_url}/api/species`;

// battle.service.ts
private readonly url = `${environment.api_url}/api/battles`;

// battle-statistics.service.ts
private apiUrl = `${environment.api_url}/api/battle-statistics`;

// dashboard.service.ts
private readonly url = `${environment.api_url}/api/dashboard`;
Changing api_url in an environment file automatically redirects all API traffic in that build target — no other files need to be touched.
Angular bakes environment values directly into the compiled JavaScript bundle at build time. There is no runtime configuration mechanism — you cannot change api_url after the bundle has been produced without rebuilding the application.

​
Switching Configurations with pnpm Scripts

pnpm run dev
Runs ng serve --configuration development. Angular replaces environment.ts with environment.development.ts, so all API calls go to your local backend at http://localhost:8080. Source maps are enabled and optimizations are disabled for a faster edit-refresh cycle.

​
Docker Build-Time Injection

The Dockerfile uses a two-stage build: a Node builder stage compiles the Angular app, and an Nginx runner stage serves the static output. The builder stage exposes an ARG API_URL that can be overridden at docker build time. Before running pnpm run build, the Dockerfile injects the API URL directly into environment.ts using sed: 
# Build argument — defaults to local backend if not provided
ARG API_URL=http://localhost:8080

# Inject API_URL into the Angular environment file before building
RUN sed -i "s|api_url: '.*'|api_url: '${API_URL}'|g" src/app/environments/environment.ts

RUN pnpm run build
This replaces whatever string value api_url holds with the value of $API_URL, then proceeds with the production build. The result is a bundle baked with exactly the URL you specified at image build time.

​
Building the Docker Image

docker build \
  --build-arg API_URL=https://galactic-tournament-app-production.up.railway.app \
  -t galactic-tournament-front:latest .
Because the sed command targets the api_url: '...' pattern in environment.ts, it works regardless of which URL was previously stored there. You can safely re-run the Docker build with a different API_URL without editing any source files.

​
Environment Fields Reference

FieldTypeDescription
productionbooleantrue only in environment.prod.ts. Can gate debug tooling or logging inside the app.
api_urlstringBase URL for all backend HTTP requests. No trailing slash.

Build docs developers (and LLMs) love

Get started for freeTalk to us