Cordis Dependencies: Runtime Libraries and Dev Tools in the Monorepo
Cordis relies on just two runtime libraries—cosmokit and @standard-schema/spec—across its core framework and official plugins, while development tools are isolated to the root package.
Cordis is a modular, plugin-based framework maintained in the cordiverse/cordis repository and structured as a Yarn workspaces monorepo. Understanding the Cordis dependencies is straightforward because the project maintains a deliberately minimal runtime footprint, with most packages sharing a single common utility library to ensure consistency and reduce bundle size.
Runtime Dependencies for the Core Framework
The core cordis package, defined in packages/core/package.json, declares only two production dependencies:
cosmokit ^1.8.1— Provides essential utilities for the Cordis ecosystem@standard-schema/spec ^1.1.0— Implements the Standard Schema specification for type validation
This intentional minimalism keeps the framework lightweight. When you install the base framework via npm, you bring in exactly these two libraries plus their transitive dependencies.
Dependencies Across Official Cordis Plugins
Every official plugin and utility package in the monorepo depends solely on cosmokit ^1.8.1. This unified approach eliminates version conflicts and simplifies the dependency graph.
The following packages each declare cosmokit ^1.8.1 as their only runtime dependency in their respective package.json files:
@cordisjs/utils— Helper utilities (packages/utils/package.json)@cordisjs/plugin-timer— Timer service (packages/timer/package.json)@cordisjs/plugin-loader— Module loading (packages/loader/package.json)@cordisjs/plugin-include— File inclusion (packages/include/package.json)@cordisjs/plugin-hmr— Hot module replacement (packages/hmr/package.json)@cordisjs/plugin-logger-console— Console logging (packages/logger-console/package.json)@cordisjs/plugin-group— Plugin grouping (packages/group/package.json)@cordisjs/create— Project scaffolding (packages/create/package.json)
Development Dependencies in the Root Package
The root package.json contains no runtime dependencies. Instead, it houses development and build tools required for maintaining the monorepo:
{
"devDependencies": {
"eslint": "...",
"vitest": "...",
"esbuild": "...",
"tsx": "...",
"yakumo": "..."
}
}
This strict separation ensures that consumers of Cordis libraries never install unnecessary build tools, while contributors still have access to the full toolchain for testing and bundling.
Working with Cordis Dependencies in Practice
When building applications with Cordis, dependency resolution happens automatically through the shared cosmokit base. The following example demonstrates importing the core framework alongside timer and loader plugins:
import { Cordis } from 'cordis'
import { useTimer } from '@cordisjs/plugin-timer'
import { useLoader } from '@cordisjs/plugin-loader'
// The core itself only needs the runtime deps shown above.
// Plugins pull in the same `cosmokit` version automatically.
const app = new Cordis()
// Register plugins
app.plugin(useTimer())
app.plugin(useLoader())
// Use the timer service
app.timers.setTimeout(() => console.log('tick'), 1000)
Similarly, utility functions from @cordisjs/utils require only the shared cosmokit foundation:
// Example: Using the utils package (also just depends on cosmokit)
import { resolve } from '@cordisjs/utils'
const path = resolve(import.meta.url, '../config.yml')
console.log(path)
Summary
- Cordis dependencies are intentionally minimal, consisting of only
cosmokitand@standard-schema/specfor runtime. - Every official plugin depends exclusively on
cosmokit ^1.8.1, ensuring consistent versioning across the ecosystem. - The root
package.jsoncontains development tools only—no runtime dependencies—keeping published packages lightweight. - Source files such as
packages/core/package.jsonandpackages/timer/package.jsonexplicitly declare these constraints in thecordiverse/cordisrepository.
Frequently Asked Questions
What are the runtime dependencies for Cordis?
The Cordis core framework depends on exactly two runtime libraries: cosmokit at version ^1.8.1 and @standard-schema/spec at version ^1.1.0. All official plugins extend this foundation by depending only on cosmokit, creating a flat, predictable dependency tree.
Does Cordis install development tools when I use it in my project?
No. The root package.json in the cordiverse/cordis repository includes development dependencies like eslint, vitest, esbuild, and yakumo, but these are not part of the published packages. When you install cordis or any official plugin from npm, you receive only the minimal runtime dependencies specified in that package's individual package.json.
Which Cordis packages depend on @standard-schema/spec?
Only the core framework package (cordis) defined in packages/core/package.json declares @standard-schema/spec as a dependency. The official plugins and utility packages rely solely on cosmokit for their functionality, as they do not require the schema validation specifications directly.
How does Cordis maintain dependency consistency across plugins?
All packages in the monorepo pin cosmokit to the same version constraint (^1.8.1), which Yarn workspaces resolve to a single installation across the repository. This shared version constraint prevents diamond dependency issues and ensures that all plugins operate against identical utility function implementations.
Have a question about this repo?
These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:
curl -s "https://instagit.com/install.md" Maintain an open-source project? Get it listed too →