Doh.js Documentation

JavaScript

Doh recognizes that all software operates through namespace resolution and provides battle-tested conventions for making incompatible namespace systems work together. After years of production use, it has evolved from a collection of specific solutions into a framework for creating and extending namespace interoperability. If you're new to Doh.js, start with the homepage to understand the foundational concepts.

The Namespace Resolution Reality

Objects, modules, databases, filesystems—they're all doing the same fundamental operation: namespace resolution. When you access object.property, import a module, or navigate a file path, you're using a namespace system. The friction in modern development comes from each system using incompatible conventions for the same operation.

Rather than force everything into one universal system, Doh provides a framework for making these different namespace systems compose naturally.

Melding as a Primitive

Melding is controlled composition of namespaces with explicit rules. When different namespace systems need to work together, melding determines HOW they combine: Do methods override or chain? Do arrays merge or replace? Do objects shallow or deep merge? The framework provides a matrix of strategies that apply based on the specific interface requirements.

Key Namespace Incompatibilities and Solutions:

Object Property Collision: MOC (Melded Object Composition) provides explicit rules for how properties combine during inheritance
Module Parameter Binding: SPR (Scoped Parameter Resolution) allows parameters to resolve by name through scope chains
Configuration Override Complexity: Pod deep-melding with sparse inheritance and removal operators (~~)
Path Resolution Fragility: DohPath provides context-relative resolution that works across environments

Framework Characteristics:

Situational Rules: No universal solution—each namespace incompatibility gets appropriate melding strategies
Extension Points: The framework adapts to new namespace systems without breaking existing patterns
Composition Matrix: Multiple strategies available, applied based on specific interface needs
Production Validated: Over a decade of evolution across security systems, data pipelines, and development tools

→ Learn more about composition strategies

Manifests Instead of Transpilation

We wanted to inject arguments into callbacks by name and move modules around without breaking references. The Auto-Packager emerged to solve this—AST parsing scanned source code to understand what each module needed, built dependency graphs, generated manifests. Load order calculated at build time, not runtime.

Unlike transpilation, your source code remains unchanged. The Auto-Packager generates structured metadata that describes your application's complete dependency graph, function signatures, inheritance chains, and component relationships.

Auto-Packager Analysis:

Static Structure: AST parsing of modules, patterns, and dependencies
Dependency Graphs: Resolution Order computation for all composition types
Parameter Signatures: Function analysis for Scoped Parameter Resolution (SPR)
Inheritance Chains: Pattern hierarchy analysis with MOC rule compilation

Runtime Execution:

Manifest-Driven Loading: Dependency injection via pre-computed metadata
Original Source: No transpilation—your code executes as written
Import Maps: NPM modules processed through esbuild, available at original specifiers
Performance: Complex operations become simple data structure lookups

Manifest Contents:

{
  "dependencies": { /* Resolution Order graphs */ },
  "patterns": { /* Inheritance chains & MOC rules */ },
  "parameters": { /* SPR signatures */ },
  "imports": { /* Module specifier mappings */ }
}

→ Explore Auto-Packager and manifest generation

Building on Existing Systems

Doh doesn't replace the tools you know—it provides conventions for making them work together naturally. You can still write standard ES Module imports; the Auto-Packager adds intelligence, handling installation, versioning, and cross-environment compatibility automatically. The framework extends existing systems rather than replacing them, so your knowledge remains valuable while gaining new composition capabilities.

Complete Ecosystem

What started as extending $(document).ready() became a comprehensive development ecosystem. Over a decade of testing one simple insight across every challenge we encountered created the following surprisingly large collection.

Core Infrastructure

Load System & Auto-Packager: Universal dependency loading with build-time analysis

Cross-environment compatibility (Node, Browser, Bun)
Automatic NPM installation from import statements
Manifest generation for runtime optimization
Born from: Wanting to inject args by name and move modules around without breaking references

DohPath: Universal path resolution across environments

Project-relative (/), context-relative (^/), and package (^:pkg/) paths
Unified API for Node, Browser, and virtual filesystems
Born from: Moving modules around broke assets, needed path resolution that worked regardless of file location

Patterns & MOC: Multiple inheritance object composition

Melded Object Composition (MOC) for property melding rules
Lifecycle phases with async support
Sub-object building and hierarchy management
Born from: Original multiple inheritance research and diamond problem solving

Modules & SPR: Dependency injection with parameter resolution

Scoped Parameter Resolution by name, not position
Environment branching with conditional loading
Async module initialization support
Born from: Extending jQuery's $(document).ready() for dependency awareness

Pods: Sparse configuration with deep melding

YAML-based hierarchical configuration
Deep merge with array uniquing and key removal
Environment-specific overrides
Born from: Modules needed configuration defaults without massive config files

Application Systems

Express Router: Protocol-agnostic HTTP/WebSocket routing

Unified route handling for both HTTP and WebSocket protocols
File-based routing with automatic middleware integration
Born from: Node.js needed web servers, Express was perfect—just needed module system integration

Cloud Manager: Multi-instance orchestration

Distributed Doh instance management
File synchronization and log aggregation
Born from: Managing multiple Doh servers required unified orchestration

Data Pipeline: Cross-environment data processing

Declarative pipelines working identically across Node/Browser/Bun
Database abstraction with synchronous APIs
Born from: Data processing needed to work the same across all environments

Security & Identity

User System: Authentication and session management

JWT authentication with multi-device sessions
Email verification and brute-force protection
Born from: Web applications needed secure user management integrated with the module system

Permission System: Context-aware authorization

Runtime object evaluation: Doh.permit(user, 'action:context', runtimeObject)
Role-based access with object-level security
Born from: Complex applications needed fine-grained permission control

Development Tools

Browser IDE: Web-based development environment

VS Code-compatible editor with live filesystem access
Terminal integration via server-side PTY processes
Born from: Developing Doh applications needed better tooling integration

MCP Server: AI assistant integration

AST-powered code search and analysis
Browser automation via Playwright
Born from: AI assistants needed deep understanding of Doh application structure

Start Building on the Foundation

1. Install Doh CLI

Windows:

powershell -c "irm deploydoh.com/install.ps1 | iex"

Mac/Linux:

curl -fsSL https://deploydoh.com/install | bash

2. Install a Package Manager

Bun:

doh install bun

OR

Node:

doh install node

3. Create Your App

doh init webserver

4. Run & Develop

doh run

Your new project runs at http://localhost:3000 with HMR—no build config required.