BartoszJarocki/cv: a print-friendly CV built on Next.js and shadcn/ui

What BartoszJarocki/cv actually replaces

Most resume tools assume you will drag boxes around a canvas and export a PDF. This project takes the opposite position: the resume is a data structure, the page is a React component tree, and the print output is a stylesheet concern. The README describes it as a "simple web app that renders a minimalist CV with print-friendly layout", and the repository confirms that framing. There is no admin panel, no database and no authentication in the top-level entries.

The intended user is a developer who already keeps a personal site or a GitHub Pages deploy and wants the CV to live in the same workflow. Editing means opening src/data/resume-data.ts and changing values. Reviewing means reading a diff. Publishing means pushing to a host that runs Next.js, or building the container. If your resume changes twice a year and you dislike re-formatting a Word document each time, that trade is favourable. If you want to hand the file to a recruiter who will edit it, it is not.

One data file, six section components

The project structure in the README is unusually explicit, which makes the data flow easy to follow. Everything the reader sees starts in src/data/resume-data.ts, exported as a constant named RESUME_DATA. That object is imported by page-level components under src/app/components: header.tsx, summary.tsx, work-experience.tsx, education.tsx, projects.tsx and skills.tsx. Each component owns one band of the page and reads only the fields it needs.

Shared pieces sit outside the app directory. src/components/ui holds shadcn/ui primitives, src/components/icons holds the social icons, and src/lib contains types.ts, utils.ts and structured-data.ts. The presence of structured-data.ts is worth noting: the app emits machine-readable metadata alongside the visible page, which is the kind of detail a hand-written HTML resume usually lacks. The root layout at src/app/layout.tsx carries the metadata, and page.tsx assembles the sections.

The consequence is that adding a section is a code change, not a config change. You edit types.ts, add a component, and wire it into page.tsx. That is a real cost, and the README does not pretend otherwise: customization is documented as editing the data file, with Tailwind colours changed in tailwind.config.js and global styles in src/app/globals.css.

Installing it and editing your first resume

The README's getting-started block is the shortest path. It clones the repository, installs with pnpm, and starts the Next.js dev server on port 3000. The package manager matters here: pnpm-lock.yaml is committed and the Dockerfile activates pnpm through corepack, so mixing in npm or yarn will not match the lockfile.

git clone https://github.com/BartoszJarocki/cv.git
cd cv
pnpm install
pnpm dev
# open http://localhost:3000
# edit src/data/resume-data.ts to customize

After pnpm dev, the terminal prints the local URL and the browser shows the rendered CV. From there, the README's customization example shows the shape of the data object you are editing: name, initials, location, about and summary, with the comment "// ... more fields" standing in for the rest.

// src/data/resume-data.ts
export const RESUME_DATA = {
  name: "Your Name",
  initials: "YN",
  location: "Your City, Country",
  about: "Brief description",
  summary: "Professional summary",
  // ... more fields
}

Because the file is TypeScript and the project ships types.ts, a wrong field name should surface at build time rather than silently render nothing. The README does not enumerate every field, so read types.ts before assuming a key exists.

For a self-hosted deploy, the repository includes a Dockerfile and a docker-compose.yaml. The compose file maps port 3000, sets NODE_ENV=production, adds a healthcheck that curls localhost:3000, and caps the service at 1 CPU and 512M of memory.

docker compose build     # build the container
docker compose up -d     # run the container
docker compose down      # stop the container

The Dockerfile is a multi-stage build on node:22-slim: a deps stage runs pnpm install --frozen-lockfile, a build stage runs pnpm build, and the runner stage copies .next/standalone and starts it with node server.js as a non-root nextjs user. That layout assumes Next.js standalone output is enabled, which is configured in next.config.js rather than in the README.

Print output is the whole point, and the hardest part to verify

A CV that looks fine in a browser and breaks across a page boundary is useless. The project claims a print-friendly layout, and the component split into discrete sections (work experience, education, projects, skills) is the mechanism that makes page breaks tractable: each band can be kept together. What the README does not provide is a print stylesheet walkthrough, any guidance on page-break rules, or a sample PDF. If you need a specific page count, you will be tuning that yourself.

The same gap applies to ATS parsing. Many employers still run resumes through text extractors, and a React page rendered to PDF produces whatever the browser's print engine emits. The repository includes structured-data.ts, which suggests the author thought about machine readability, but the README does not claim ATS compatibility and nothing here measures it. Treat the printed output as something to check against a real job application before you rely on it.

There is also no versioning or rollback story. The README does not document rollback, and there are no retrieved releases, so a bad edit is corrected by reverting a commit. That is normal for a personal site and awkward for anyone expecting staged drafts.

How it compares with JSON Resume and hosted builders

JSON Resume takes the data-driven idea further by standardising the schema itself. Its format is a published specification with themes that consume it, so a resume written once can be rendered by many tools. This project inverts that: the schema is local to src/data/resume-data.ts and typed in src/lib/types.ts, and the renderer is the app. You get a specific design and a working print layout out of the box, but no portability if you later want a different theme or a different generator, because your content is shaped to this project's types.

Hosted builders sit at the other end. They give you a visual editor, templates and PDF export without a build step, at the cost of your resume living inside someone else's product. BartoszJarocki/cv sits in the middle: more control than a builder, less portability than JSON Resume, and a deployment story (Vercel button in the README, Docker files in the repository) that neither of the others matches directly.

Toolchain, licence and the cost of keeping it current

The stack is deliberately current: Next.js 16, React 19, TypeScript 5, Tailwind CSS 3.4, Biome 2.0.6 for linting and formatting, shadcn/ui components built on Radix primitives, and Geist for type. The scripts in package.json split lint, format and check into plain and auto-fix variants, so pnpm check is the single command for a clean tree and pnpm check:fix writes the fixes.

That currency is also the maintenance bill. Next.js and React major versions move quickly, and a personal CV repo tends to be touched rarely, which means upgrades arrive in one large jump rather than small ones. The last push was on 2026-03-03, so the dependency set reflects that date rather than today. Budget an afternoon for a major Next.js bump, and expect the shadcn/ui components under src/components/ui to need review when Radix packages move.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The repository contains a single LICENSE file at the top level, and there is no separate licence for the resume content itself, which is worth noting because the sample data in resume-data.ts is the author's own. Replace it rather than ship it. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt it if you are comfortable editing TypeScript and want a CV you can version, print and host yourself. Skip it if you need a CMS, multi-language content or a visual editor, because none of those appear in the repository. Before committing, open src/data/resume-data.ts and confirm its shape matches your history, then run pnpm build and print the result to check the layout survives your longest job title.

Frequently asked questions

Official sources

1. BartoszJarocki/cv on GitHub
2. Issues
3. License: MIT
4. Project website
5. README