Skip to main content

About datamitsu

Your toolchain deserves a home​

Stop setting up the same tools in every repository. Linters, formatters, git hooks and the runtimes they need go into one datamitsu.config.js you carry from project to project.

Define them once. Inherit them everywhere.

Not a boilerplate, not scattered across projects, not reinvented from scratch every time. datamitsu gives your toolchain one home — versioned, composable, and always one command away.

Why it exists​

Dozens of repositories, all on different stacks — a Typst document with scripts, a frontend, a backend, a CLI, a slide deck. Every new project meant weeks of setting up the same tools, and every setup came out slightly different. Updating twenty repositories was hell, so they went years without updating their linters — until eslint started getting in the way of the product.

— Alexander Svinarev, author of datamitsu

What is datamitsu?​

datamitsu is a platform for building reproducible, security-first development tool distributions.

It's NOT just another task runner or runtime manager.

It's a foundation for creating standardized tool configurations that teams can distribute as packages (npm, rubygem, pypi, etc).

Think of it as "lefthook for linting/tooling ecosystems":

  • Core binary provides secure tool delivery (SHA-256 verification)
  • Wrappers provide opinionated configs for different ecosystems
  • Teams install one package, get everything configured

The Two-Level Architecture​

datamitsu operates on a two-level architecture that separates the platform from the content:

Level 1: The Core (datamitsu)​

The datamitsu binary provides the platform capabilities:

  • Binary management with SHA-256 verification
  • Programmable JavaScript configuration (goja runtime)
  • Declarative + imperative configuration approach
  • Config chaining with inheritance
  • Tool operations (fix/lint/check)
  • Safe managed-config reconciliation
  • File patching (gitignore/dockerignore/package.json)

What the core does NOT contain:

  • Concrete tool versions
  • Linter configurations
  • Opinionated defaults

Level 2: Wrappers (npm/gem/pypi packages)​

Wrapper packages provide the actual tool configurations:

  • Full tool suite (eslint/prettier/golangci-lint/etc)
  • Configured defaults for all tools
  • VS Code recommendations
  • Exportable config functions
  • Project type detection
  • Migration-free updates (via patching)

Distribution Model​

datamitsu core (Go binary)
  ↓
  Provides: binary mgmt, config engine, managed-config reconciliation

Wrappers (language-specific packages)
  ↓
  Provide: tool versions, configs, project templates

Projects (end users)
  ↓
  Install: npm install @company/dev-standards
  Run: datamitsu config reconcile && datamitsu lint

This architecture enables teams to:

  1. Build once, distribute everywhere — Create your company's tool standards as a package
  2. Version independently — Update configs without waiting for tool releases
  3. Distribute via familiar channels — Use npm, gem, pypi, or any package manager
  4. Enforce security policies — Mandatory hash verification for all binaries

Who is datamitsu for?​

Primary: Config Package Creators​

Who they are:

  • Platform engineers at companies
  • Open source maintainers
  • DevOps teams establishing standards

What they need:

  • Create company-wide tool standards
  • Distribute via familiar package managers
  • Enforce security policies (hash verification)
  • Version configs independently from tools

Value proposition:

"Build once, distribute everywhere. One package brings all tools and configs to every project."

Secondary: Development Teams​

Who they are:

  • Teams tired of copy-paste configs
  • Projects with multiple contributors
  • Companies wanting standardization

What they need:

  • One dependency = all tools configured
  • No manual setup per project
  • Docker-optimized CI/CD
  • Migration-free updates

Value proposition:

"Install one dependency, get everything configured. Zero manual setup in new projects."

Tertiary: Open Source Maintainers​

Who they are:

  • Project template creators
  • Framework maintainers
  • Tool distribution authors

What they need:

  • Distribute project templates with tools
  • Ensure contributors use correct versions
  • Provide both CLI and programmatic access

Value proposition:

"Ship your project template with tools included. Contributors get the right setup automatically."

What makes datamitsu unique?​

1. Mandatory Security Verification​

Every binary downloaded from the internet must have a SHA-256 hash specified. No exceptions. No bypassing. Hash verification happens before extraction, preventing malicious binaries and ensuring reproducibility.

2. Config Chaining and Inheritance​

Layer configurations from base → company → team → project:

// Project-specific override in datamitsu.config.ts
function getConfig(prev) {
  return {
    ...prev,
    apps: {
      ...prev.apps,
      // Remove a tool for this project
      "some-linter": undefined,
    },
  };
}

globalThis.getConfig = getConfig;
globalThis.getMinVersion = () => "0.0.1";

Configs receive the previous layer as input, enabling composition without duplication.

3. Docker CI/CD Optimization​

Pre-cache all tools in a Docker layer for fast, reproducible builds:

FROM node:20-alpine

# Install datamitsu + config wrapper
RUN npm install -g @company/datamitsu-config

# Download ALL tools to global store
RUN datamitsu init --all

# Save this layer
# Only changed tools re-download on updates

This dramatically speeds up CI builds by avoiding tool downloads on every run.

4. Migration-Free Updates​

Update your config package, optionally preview the reconciliation, then run it; your customizations survive:

# Update config wrapper
npm update @company/datamitsu-config

# Preview without writing or fixing
datamitsu config reconcile --dry-run

# Reconcile files, then run fix (preserves customizations!)
datamitsu config reconcile

The patching mechanism merges new defaults with your project-specific changes.

5. Multi-Runtime Support​

Manage tools from different ecosystems in one place:

  • Binary apps — Download native binaries with hash verification
  • UV apps — Python tools via managed UV runtime (e.g., yamllint)
  • Node apps — npm packages via managed Node.js + pnpm (e.g., eslint, prettier)
  • JVM apps — Java applications via managed JDK runtime (e.g., openapi-generator-cli)
  • Go apps — Go tools built from source via managed Go SDK (e.g., govulncheck)
  • Shell apps — Wrap arbitrary system commands

All managed with the same config API, all with hash verification. Any app kind can set custom environment variables (with ${STORE}/${APP_DIR} expansion) via the shared env field.

Where does datamitsu fit?​

datamitsu is NOT:

  • A task runner (use moon/nx/turborepo for that)
  • A runtime manager (use mise/asdf/volta for that)
  • A package manager (use npm/pnpm/cargo for that)
  • A build system (use moon/bazel/gradle for that)

datamitsu IS:

  • A platform for building config distributions
  • A foundation for team standards
  • A delivery mechanism for verified tools
  • A configuration system with inheritance

For detailed comparisons with similar tools, see the Comparison Guide.

Use Cases​

Company-Wide Standards​

Scenario: Enterprise wants all projects to use the same linters and formatters.

With datamitsu:

# Create @company/dev-standards package once
# Then in every project:
npm install @company/dev-standards
datamitsu config reconcile  # Creates all configs automatically

Result:

  • One source of truth for all configs
  • Update package → all projects can update
  • Enforce via package.json dependency

Docker-Based CI/CD​

Scenario: GitLab CI pipeline needs linting tools.

With datamitsu:

# Base image - run once
RUN datamitsu init --all
# Layer cached with all tools

# Project build - runs every time
RUN datamitsu check
# Only new/changed tools download

Result:

  • Fast CI builds (tools pre-cached in layer)
  • Reproducible (hash-verified binaries)
  • Incremental updates (only changed tools re-download)

Open Source Project Template​

Scenario: Framework wants contributors to have consistent setup.

With datamitsu:

{
  "dependencies": {
    "@framework/dev-tools": "^1.0.0"
  }
}

Run npm install && npx datamitsu config reconcile → Everything configured automatically.

Result:

  • Contributors get identical setup
  • No "how to configure" docs needed
  • Updates propagate via package version bump

Learn More​