eidos

eidos generates code. A frontend parses your source into a symbol graph that belongs to no language. Plugins annotate that graph and produce output entities. A backend renders those into a target language. One run regenerates only what changed, produces the same bytes every time, and can target several languages at once.

The binary eidos runs the declarative plugins of your workspace. Install it with brew install --cask dokimasia/tap/eidos, from the archive of a release, or with go install go.dokimi.dev/eidos/cmd/eidos@latest. The go command needs a C compiler for the tree-sitter frontends. A team with typed plugins builds its own binary on the command kernels. Its users install that binary.

eidos is not released yet. The specification is complete, and the module table says what each module contains. Start with one declaration, end to end, which follows one declaration through the whole system.

Modules

Each component is its own module in this repository, tagged and released on its own as eidos-core/v0.1.0. The kernel changes slowly and breaking it is expensive. Catalogs and language support change often, so they release on their own schedule.

Module	Import path	Contents
cmd/eidos	go.dokimi.dev/eidos	the binary eidos: the frontends of every language, the rules of Go, TypeScript, protobuf and GraphQL, and one extensible plan for each target. A workspace adds its declarative plugins to the plans
eidos-core	go.dokimi.dev/eidos/core	the kernel: the symbol, node and emit models, metadata, directives, diagnostics, the store, projection rules, the plugin SPI and authoring surface, the frontend and backend kits, output, the workspace, the toolchain harness and the conformance kits
eidos-sdk	go.dokimi.dev/eidos/sdk	the generated facade plugin modules import: one re-export per exported symbol of the kernel's plugin-facing packages
eidos-cli	go.dokimi.dev/eidos/cli	the command kernels that every binary built with eidos offers: the config file and its JSON Schema, the shared flags, the rendering of findings and the exit statuses
eidos-declarative	go.dokimi.dev/eidos/declarative	the declarative host: the loader that builds a generator from a plugin directory of a YAML manifest and template trees, and the JSON Schema of the manifest
eidos-conformance	go.dokimi.dev/eidos/conformance	the cross-language corpus: one feature inventory and one set of expectations that every language's frontend is checked against
eidos-lang	go.dokimi.dev/eidos/lang	the helper packages the satellites share: lowering, naming, numeric, scaffold, spellref and textfmt
eidos-lang-go	go.dokimi.dev/eidos/lang/go	Go satellite: frontend, projection rules, annotator, backend and the toolchain adapter for generated tests
eidos-lang-typescript	go.dokimi.dev/eidos/lang/typescript	TypeScript satellite: backend and the toolchain adapter for generated tests
eidos-lang-protobuf	go.dokimi.dev/eidos/lang/protobuf	protobuf satellite: frontend, projection rules, backend and the toolchain adapter for generated schemas
eidos-lang-graphql	go.dokimi.dev/eidos/lang/graphql	GraphQL satellite: frontend, projection rules, backend and the toolchain adapter for generated schemas and documents
eidos-lang-java	go.dokimi.dev/eidos/lang/java	Java satellite: backend and the toolchain adapter for generated tests
eidos-lang-kotlin	go.dokimi.dev/eidos/lang/kotlin	Kotlin satellite: a statement of scope and no code
eidos-lang-php	go.dokimi.dev/eidos/lang/php	PHP satellite: a statement of scope and no code
eidos-lang-rust	go.dokimi.dev/eidos/lang/rust	Rust satellite: backend and the toolchain adapter for generated tests
eidos-plugin-shape	go.dokimi.dev/eidos/plugin-shape	the classification catalog of shapes, mixins and contracts: a statement of scope and no code
eidos-reference	go.dokimi.dev/eidos/reference	the canary of the ring: nineteen reference plugins on the SDK facade that build on each other, their composition and the binary eidos-reference over it, a workspace tree with the files that the binary writes from it, and the program of the ring job

Consumers depend on satellites, satellites depend on the kernel, and nothing depends the other way. One satellite never imports another. Anything cross-language goes through the kernel's canonical-type hub. The kernel knows no language, and its runtime packages import the standard library alone. Its conformance kits import go.dokimi.dev/assert.

go.work holds the module list and ergon reads it from there. The root module go.dokimi.dev/eidos contains the command eidos. Its go.mod has no replace directive, so go install builds the command from published modules.

Development

ergon drives the build, the tests, the linters and the releases:

make check        # the gate: lint, test, race and audit in every module
make fmt          # the formatters of .golangci.yml
make help         # every target

Write Conventional Commits, scoped by module name, such as feat(core): or fix(go):. .commitlint.yaml lists the accepted types and scopes, and the commit-msg hook rejects anything else.

Contributing

CONTRIBUTING tells you how to set up, what to run before a PR, and how to write a commit message. Everyone taking part follows the Code of Conduct. Email vulnerabilities to security@dokimi.dev, as SECURITY explains.

License

Apache-2.0. See LICENSE.