The DigiFX platform runs on a deliberately small set of languages. Each one owns a specific layer, and the boundaries between them are load-bearing: they decide where type errors get caught, what has a build step, and what you can read and trust without compiling first.
01TypeScript on the front end
The Media Console client is an Angular application written in TypeScript, compiled to ES2022 modules with moduleResolution: "bundler". The compiler configuration is strict by intent, not by default: strict is on, along with noImplicitOverride, noImplicitReturns, noFallthroughCasesInSwitch, and noPropertyAccessFromIndexSignature. On the Angular side, strictTemplates, strictInjectionParameters, and strictInputAccessModifiers are all enabled.
The practical effect is that template mistakes are build failures. A misspelled property in an HTML binding, or an input passed with the wrong type, stops the build rather than surfacing as a blank panel in production. Path aliases (@app/*, @controller/*) keep imports stable when components move between feature folders.
02JavaScript on the server
The backend is a set of independently deployed Cloud Functions codebases, each written in plain CommonJS JavaScript targeting the Node 20 runtime. There is no transpile step between source and deploy: the file in functions/<name>/index.js is the file that executes.
That choice trades compile-time type checking for auditability. When a function handles money, credentials, or credit metering, being able to read the exact deployed source without a source map matters more than a type annotation. The gap is covered by tests that sit beside the source as index.test.js and inject dependencies through explicit exported seams rather than a mocking framework, so the same code path runs in test and in production.
03Shell and Node for the toolchain
Build, deploy, and verification chores are written in POSIX shell and in Node — both ES modules (.mjs) and CommonJS — under the repository's scripts/ and tools/ directories. These are small, single-purpose programs rather than a framework.
One of them illustrates why the toolchain is written in shell at all: the Firebase CLI wrapper exists solely to pin the CLI and every process it spawns to Node 20, matching the deployed runtime. A version mismatch between the local CLI and the deployed runtime produced real deployment failures, and a two-line shell wrapper is the durable fix.
04Markup, styles, and data
Component templates are HTML with Angular binding syntax, and styles ride with their components rather than in a global sheet. Relational surfaces are reached through SQL via the Postgres client and the Supabase client library. JSON is the configuration and registry format throughout — route manifests, pack registries, and codex indexes are all JSON files checked in beside the code that reads them.