01_umr

Universal Module Resolution

Universal Module Resolution (UMR)

Purpose

The Universal Module Resolution (UMR) system is the bridge that connects ARES to the global software ecosystem. It does not store actual libraries itself; instead, it stores a Dependency Grammar. This grammar is a mapping that tells the system exactly what is needed—whether it's a C++ package, a Python library, or a Node.js module—to fulfill your high-level request. This allows ARES to generate complete, buildable project environments in any of our target languages.

Why it exists

Different languages have completely different ways of managing libraries. For example, C++ uses CMake or vcpkg, Python uses pip and requirements.txt, and Node.js uses npm and package.json. If you had to manage all of these by hand, it would be incredibly difficult and prone to errors. The UMR exists to solve this problem. It allows you to simply say "use tensorflow" or "use express_server," and the system handles the task of creating the correct configuration files for whichever language you are using. It ensures your projects are always ready to be built and run.

How it works

The UMR system acts as a smart dictionary for software dependencies.

  1. Gathering requests. As the system reads your ARES code and identifies the tools you are using, it builds a list of high-level dependencies.
  2. Filtering for the target. Once the system chooses a final language (C++, Python, or TypeScript), UMR filters the list to only include the libraries that belong to that ecosystem.
  3. Generating configurations. UMR then writes the specific files needed for that language's package manager.
    • For C++, it writes a CMakeLists.txt file with all the necessary find_package and link commands.
    • For Python, it writes a requirements.txt file with the correct version numbers.
    • For Node.js, it writes a package.json file with all the dependencies and scripts needed.
  4. Injecting boilerplate. Finally, it adds any necessary standard project files to ensure the output folder is a valid, professional project directory.

Intuition

Think of UMR like a universal adapter for your electrical tools. You might have several different tools (your ARES logic), but each country you visit (the target languages like C++ or Python) has a different shaped wall outlet. UMR is the adapter that identifies which country you are in and automatically changes its shape so your tool can plug in and work perfectly. You don't need to carry a different tool for every country; you just need the universal adapter.

Implementation details

The coordination of these dependencies is handled in src/umr/umr_bridge.ts. It uses a central database to map high-level names to concrete requirements.

  • Dependency DB: A pre-defined registry of standard libraries and their multi-language metadata.
  • Version Control: If different parts of your code ask for different versions, UMR automatically selects the newest version to avoid conflicts.

Trace example

This is what happens when you use "opencv" in a C++ program:

  1. Look-up: The system finds "opencv" in its dependency database.
  2. Identification: It sees that for C++, the package is named "OpenCV" and requires a specific CMake command.
  3. Drafting: It adds find_package(OpenCV REQUIRED) to its internal list for the build file.
  4. Finalizing: It writes the full CMakeLists.txt file into your output folder, ready for you to build.

Related entities

  • 6_compiler_and_runtime/01_pipeline.md: Phase 6 of the pipeline is where UMR performs its work.
  • src/umr/umr_bridge.ts: The actual code that implements the dependency mapping.
ARES