Configuration
datamitsu uses JavaScript configuration files to define your tools, runtimes, and project settings. The configuration system supports layered composition, remote inheritance, and dynamic generation through a full JavaScript runtime.
Configuration Files
datamitsu automatically discovers configuration at your git repository root. It looks for one of these files:
datamitsu.config.jsdatamitsu.config.mjsdatamitsu.config.ts
If more than one exists, datamitsu returns an error. You can disable auto-discovery with --no-auto-config.
Every configuration file must export two functions:
getMinVersion()— Returns the minimum datamitsu version required (semver string). The loader checks this before proceeding and fails with upgrade instructions if the current version is too old.getConfig(config)— Receives the accumulated configuration from previous layers and returns a new config.
The /// <reference path=".datamitsu/datamitsu.config.d.ts" /> directive at the top of config files enables IDE autocomplete and type checking. This file is automatically generated in the .datamitsu/ directory when you run datamitsu init and contains TypeScript type definitions for the configuration API.
A minimal configuration file:
/// <reference path=".datamitsu/datamitsu.config.d.ts" />
function getConfig(config) {
return {
...config,
apps: {
...config.apps,
// your app definitions
},
};
}
globalThis.getConfig = getConfig;
globalThis.getMinVersion = () => "0.0.1";
If getMinVersion() is missing, the config fails to load with: "config must export getMinVersion() function returning semver string".
Config Loading Order
Configuration is loaded in layers, where each layer receives the result of the previous one:
default (embedded config.js)
↓ [getRemoteConfigs() resolved]
--before-config flags
↓ [getRemoteConfigs() resolved]
auto (datamitsu.config.js at git root)
↓ [getRemoteConfigs() resolved]
--config flags
↓
final Config
Each layer can modify, extend, or override the configuration from previous layers.
Default Configuration
datamitsu ships with a built-in default configuration that provides common tools and sensible defaults. This is always the starting point.
Before-Config (--before-config)
Use --before-config to load configuration files before auto-discovery. This is intended for wrapper packages and shared libraries that provide base configurations:
datamitsu check --before-config ./node_modules/@myorg/datamitsu-config/base.js
Auto-Discovery
datamitsu automatically finds and loads your project's configuration file at the git root. Disable this with --no-auto-config when you want full control over which configs are loaded.
Config Overrides (--config)
Use --config to load additional configuration files after auto-discovery. This is useful for CI-specific overrides or testing:
datamitsu check --config ./ci-config.js
Remote Configs
Any configuration file can export a getRemoteConfigs() function to inherit from remote configurations:
/// <reference path=".datamitsu/datamitsu.config.d.ts" />
function getRemoteConfigs() {
return [
{
url: "https://example.com/shared-datamitsu-config.js",
hash: "a1b2c3d4e5f6...", // SHA-256 hash (required)
},
];
}
globalThis.getRemoteConfigs = getRemoteConfigs;
Remote configs are resolved depth-first before the current config's getConfig() runs. This creates an inheritance chain where your local config can build on top of shared organization-wide settings.
Key requirements:
- Every remote config must have a SHA-256
hashfor security verification - Remote configs are cached locally; cache validity is determined by hash match (no TTL)
- Circular dependencies are detected and produce an error
- HTTPS-to-HTTP redirects are rejected for security
Wrapper Package Pattern
Remote configs enable a wrapper package pattern for sharing configuration across teams:
// @myorg/datamitsu-config/index.js
function getRemoteConfigs() {
return [
{
url: "https://config.myorg.com/datamitsu/base.js",
hash: "abc123...",
},
];
}
globalThis.getRemoteConfigs = getRemoteConfigs;
function getConfig(config) {
return {
...config,
// organization-specific overrides
};
}
globalThis.getConfig = getConfig;
globalThis.getMinVersion = () => "1.0.0";
Teams use this via --before-config:
datamitsu check --before-config ./node_modules/@myorg/datamitsu-config/index.js
Ignore Rules
Ignore rules can be defined both in .datamitsuignore files and in the configuration:
/// <reference path=".datamitsu/datamitsu.config.d.ts" />
function getConfig(config) {
return {
...config,
ignoreRules: [
"*.generated.ts: eslint, prettier",
"vendor/**/*: *",
"!vendor/important.go: golangci-lint",
],
};
}
globalThis.getConfig = getConfig;
Config-defined ignore rules use append semantics across config layers -- previous rules are preserved and new rules are added.
See the Ignore Rules reference for full syntax documentation.
JavaScript Runtime
Configuration files run in a JavaScript VM (goja) with access to several built-in APIs:
- Format utilities:
YAML.parse()/YAML.stringify(),TOML.parse()/TOML.stringify(),INI.parse()/INI.stringify()for parsing and generating config file content - Path utilities:
tools.Path.join(),tools.Path.abs(),tools.Path.rel(),tools.Path.forImport() - Config links:
tools.Config.linkPath()for computing paths to.datamitsu/symlinks - Ignore utilities:
tools.Ignore.parse(),tools.Ignore.stringify()for working with ignore patterns - Facts:
facts()returns platform and environment information (os,arch,isInGitRepo,isMonorepo,env) - Console:
console.log(),console.warn(),console.error()for debugging
See the Configuration API reference for complete API documentation.
Environment Variables
| Variable | Description | Default |
|---|---|---|
DATAMITSU_CONCURRENCY | Concurrent downloads during init | 3 |
DATAMITSU_MAX_PARALLEL_WORKERS | Max parallel tool workers | max(4, floor(NumCPU * 0.75)), capped at 16 |
DATAMITSU_NO_SPONSOR | Suppress sponsor messages | - |
NO_COLOR | Disable color output | - |
FORCE_COLOR | Force color output | - |