YAMLResume: Version-Controlled Resumes from YAML

Why YAMLResume Stores a Resume as a Compiler Input

YAMLResume targets the repeated editing and formatting work involved in maintaining a resume, especially for people who already work with source files, Git, and automated build pipelines. The resume content lives in a plain-text `resume.yml`, so changes can be reviewed line by line, compared across revisions, and copied without relying on a visual editor's proprietary project format.

The central design is separation of concerns. YAML holds the content, the compiler and strict schema handle structure and validation, and layout engines handle presentation. This makes the tool different from a form that writes an opaque document directly. It also introduces a development workflow: users become responsible for YAML syntax, the accepted schema, typography settings, and the availability of output dependencies.

The intended audience is therefore narrower than the phrase "resume builder" might suggest. YAMLResume is most relevant to developers, technical professionals, and users who want CI generation. The repository also provides a browser Playground, but the README does not document a complete offline graphical editing workflow. A user who mainly wants to drag fields into a form may find that model less direct than the compiler model.

YAMLResume's Parse, Validate, Transform, and Render Pipeline

The README describes YAMLResume as a resume compiler rather than a template form. Its documented pipeline is parse, validate, transform, and render. Runtime validation uses Zod, while JSON Schema integration supports editor validation. A malformed or structurally unacceptable YAML document can therefore be rejected before a document is produced.

One YAML source can feed several layout engines. The documented outputs are PDF through LaTeX, Markdown, responsive HTML, and Microsoft Word DOCX. The CLI also creates an intermediate TeX file during a PDF build. That intermediate artifact gives users something specific to inspect when LaTeX processing fails, although the README does not document a supported workflow for editing the TeX file and feeding those changes back into YAML.

Layout choices are described as pluggable, while the feature list identifies LaTeX, HTML, Markdown, and DOCX as presentation engines. Section names and ordering can be changed, templates can be switched, and typography, paper size, line spacing, and icons can be adjusted. The documentation also reports support for 10 languages across 12 locale codes. This architecture favors repeatable transformation from one structured source, but it does not mean every layout exposes identical typographic control.

Installing YAMLResume and Producing the First PDF

The quickest documented route is Docker. The image contains the CLI, XeTeX, and recommended fonts, which avoids a separate local typesetting-engine setup. Mount the current directory so that generated files return to the host directory, then create and build a resume:

docker run --rm -v $(pwd):/home/yamlresume yamlresume/yamlresume new my-resume.yml
docker run --rm -v $(pwd):/home/yamlresume yamlresume/yamlresume build my-resume.yml

The first command creates `my-resume.yml`. The second builds the available outputs. The README example reports a TeX file, PDF, DOCX, Markdown, and HTML file.

A native installation requires Node.js 22 or later. Choose only the package-manager command that already exists in the target environment:

npm install -g yamlresume
pnpm add -g yamlresume
yarn global add yamlresume
bun add -g yamlresume
brew install yamlresume

After installation, inspect the CLI and environment diagnostics:

yamlresume help
yamlresume doctor

`yamlresume help` lists available commands, while `yamlresume doctor` checks the environment. The installation guide is also the documented source for configuring a typesetting engine when the Docker route is not used.

Editing YAML, Watching Changes, and Generating a Resume

The repository points new users to the software engineer fixture as a sample resume. Copying its structure is safer than inventing field names, because the compiler enforces a strict schema and uses runtime validation. After editing a local YAML file, invoke the normal build command with that filename:

yamlresume build my-resume.yml

The documented build output includes `my-resume.tex`, `my-resume.pdf`, `my-resume.docx`, `my-resume.md`, and `my-resume.html`. These are example filenames derived from the input. The README does not provide individual format-selection flags, so a user should consult the CLI documentation rather than assume that one command can disable unwanted outputs.

For an edit-and-rebuild loop, the documented `dev` command watches the resume and rebuilds it after file changes:

yamlresume dev

The README calls this a web-development-like experience, but it does not explain which files it watches or whether an interactive terminal is required. For recurring automation, the project also links to a YAMLResume GitHub Action for PDF builds in CI/CD. Its existence supports a pipeline use case, but the repository overview does not provide the action's configuration syntax.

YAMLResume's Schema and Typesetting Boundaries

YAMLResume has a meaningful dependency boundary: generating a document is not the same as guaranteeing that the build environment supports every renderer. The Docker image is especially relevant because it includes the CLI, XeTeX, and recommended fonts. A native installation may require additional typesetting setup, which the README handles by directing readers to the separate installation guide.

Schema validation is also a constraint rather than only a convenience. Because content and structure are checked by a strict schema, a YAML file that parses successfully can still fail validation if it contains unsupported fields or an incorrect shape. Editor diagnostics may catch some problems early, but the exact rules must be read from the schema or sample files. The README does not publish a complete field reference.

The project offers several outputs, but that breadth raises compatibility questions. LaTeX and XeTeX involve a native document toolchain, while DOCX, HTML, and Markdown have different renderer dependencies. The repository lists package-manager and Docker distribution, but it does not promise identical feature coverage across all formats. Before standardizing on YAMLResume, check that the required layout engine and template settings behave correctly for the user's actual document.

JSON Resume Conversion Versus Direct YAML Editing

A real alternative is to maintain a JSON Resume document and convert it into YAMLResume before building the final outputs. The repository explicitly includes a `json2yamlresume` package and describes a JSON Resume converter. The difference is the ownership boundary. JSON Resume users can continue using an existing JSON-oriented workflow or tooling and invoke conversion at the point where YAMLResume is needed, while direct YAMLResume users edit the strict YAML schema as the maintained source.

Another practical alternative is a graphical resume editor. That approach shifts effort away from schema maintenance and toward visual controls, which can be more appropriate when resume formatting is occasional work. YAMLResume instead makes revisions inspectable and supports automated builds, but users must accept YAML syntax and layout configuration as part of resume maintenance.

A LaTeX-first workflow is also a meaningful comparison because YAMLResume originated as the typesetting engine for PPResume. Directly editing LaTeX offers fine control over the final document, but YAML separates content from the TeX output. The trade-off is explicit: direct LaTeX exposes the typesetting layer, while YAMLResume adds schema validation and multi-format compilation at the cost of working within its accepted content model.

YAMLResume Maintenance, Releases, and MIT Use

The repository is not archived. Its last push was on 2026-10-13, shortly after the listed releases `v0.17.0` on 2026-10-09, `v0.16.1` on 2026-09-20, and `v0.16.0` on 2026-08-28. Those dates indicate recent project activity, but they do not by themselves establish API stability. Version numbers below `1.0` and a sequence of feature releases are reasons to review the changelog when upgrading.

The main upgrade costs follow from the architecture. Users may need to review schema changes, regenerate outputs after dependency updates, and confirm that their selected templates still produce the intended layout. Native installations carry environment concerns because Node.js 22 or later is required and PDF generation may involve XeLaTeX. Docker reduces that setup burden by carrying the CLI, XeTeX, and recommended fonts, while also moving users to a packaged runtime.

The repository identifies the project as MIT licensed. The `LICENSE` file is the controlling source for its exact permissions and conditions. Anyone embedding the compiler, distributing a modified build, or operating the service should review that file and the relevant package notices. The repository's license-checking scripts are development controls, not a substitute for reviewing the license text.

Editorial conclusion

YAMLResume is appropriate for engineers and other technical users who already want to maintain a resume in Git and can support Node.js 22 or the Docker image. It is a poor fit when a graphical editor is the priority or when several proprietary layout engines must be available on one machine. Before adopting it, inspect a sample YAML file, run `yamlresume doctor`, and build that sample for every required output format. The first practical compatibility boundary is whether the intended machine can produce your required document types, especially PDF through XeLaTeX.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yamlresume/yamlresume on GitHub