Eldora UI, components you copy into your application

A collection, not a dependency

The project description is the whole pitch in one sentence, a collection of re-usable components that you can copy and paste into your web apps, and it says the collection primarily features components, blocks and templates. The subtitle places it as a UI library for design engineers, which is a narrower audience than a general component library and explains the shape of the offering. There is no dependency to add, no version to track and no runtime to load, and in exchange you hold an editable copy, subject to the licence's notice requirement. That trade is the point. A team that has been fighting a component library's theme system, or that needs a button to behave in a way the library does not allow, gets a file it can edit. The cost is that every fix, every accessibility improvement and every dependency update is now your problem, and that the codebase slowly diverges from the upstream collection as people paste different versions of the same component into different screens.

The repository is a pnpm and turbo monorepo

The root package.json describes a workspace, named @eldoraui/workspace, marked private, with pnpm pinned as the package manager at 9.15.0 and a preinstall script that runs only-allow pnpm so that npm or yarn installs fail early. Turbo drives the actual work, with dev running turbo run dev --parallel, build running turbo run build, and lint, lint:fix, typecheck and the format scripts all delegating the same way. There is a check script that chains lint, typecheck and format:check into one command, which is what a continuous integration job would run. The tooling is modern and opinionated, with commitlint configured for conventional commits, lefthook for the git hooks, and ultracite as the formatting and linting layer, plus js-yaml for the registry files. The engine requirements are explicit, Node 22.14.0 or newer and pnpm 9 or newer, which is a floor worth checking before you clone anything, since a design engineer arriving from a React project on an older Node will hit it immediately. The tree also carries a .cursor/ directory, a .vscode/ directory and an AGENTS.md, so the project expects both an editor and an assistant to work in it.

The documentation site and the registry are the product

The top level listing has an apps/ directory, and the scripts that matter point into it. The documentation lives at eldoraui.site/docs, and the build for it is a filtered turbo task, build:docs with the www filter, which tells you the docs site is an app inside the workspace rather than a separate deployment. The second, more interesting script is build:registry, which is a pnpm filter call that runs the registry build, then runs lint:fix on the same app, then a silent repository wide format fix. A registry.json file sits at the root, so the catalogue of components is a data file that the site reads, and the build has a step whose job is to regenerate it. That is a sensible design for a copy and paste library, because the registry can tell you what a component is called and where it lives before you go to copy it. It also means the component set is generated and linted rather than hand maintained, so a broken component is caught by the same build that produces the documentation, and the lint fix step in the middle of the registry build is a hint that the generator output is expected to need cleanup.

A container that runs the site as a non-root user

The Dockerfile is a careful multi stage build for a Next.js application, and it is worth reading because it shows the deployment shape of the docs site. The base is node:22-alpine with corepack enabling pnpm 9.15.0. The deps stage installs with a frozen lockfile and, importantly, with scripts ignored, and the comment explains why, to avoid postinstall issues. The builder stage copies the source in and runs a second frozen install so the postinstall scripts can execute now that the source files are available, then builds the registry first and the Next.js app second, which is the same order as the root script. The runner stage copies only the standalone output, the static assets and the public directory from the builder, and creates a non-root user with group id and user id 1001, switching to it before the container starts. The server listens on port 3000 with the hostname set to 0.0.0.0. The compose file runs the same image with the port published, NODE_ENV and NEXT_TELEMETRY_DISABLED set, a restart policy, and a healthcheck that uses wget to spider the local port every thirty seconds with a start period that allows forty seconds for the boot.

Adding your own component is a five minute job

The contributing section is unusually short, and that is part of the product's appeal. The README sends you to the contributing guide in the repository and says it only takes about five minutes to add your own. The model follows from the premise, since a component is a file you copy, adding one means creating the component, adding it to the registry so the site can show it, and opening a pull request. The review expectations live in the same guide, along with the development setup, and the repository also has a lefthook configuration for the local git hooks and a .prettierignore for the formatter. For community, there is a Discord linked from the README, and the project is part of the Vercel open source program, which is a hosting sponsorship rather than a technical feature but does mean the site has somewhere to live. The pull request template, the code of conduct and the issue templates live in the .github/ directory, so the project has the process scaffolding that a small but real community needs.

One release tag and a branch that keeps moving

The version story is the part that deserves the closest reading. There is a single release, tagged v-0.1 with the name version-2.0, published on 2024-06-02, and the package manifest at the root says version 0.1.0, which does not obviously match either the tag or the name. There are no releases after that one, while the repository is not archived and the last push was on 2026-09-26, so the branch has moved a long way past the last tag. For a project whose output is source code you copy, that is less serious than it would be for a library, since you are copying current code rather than depending on a version, but it does mean the tags tell you nothing about what is currently in the tree. The licence is MIT, stated in the README and recorded in LICENSE.md, which is the permissive choice you want when the artefact is a pile of code meant to be copied into a commercial application. A repository that gives away code under MIT and asks you to bring your own components is asking you to assemble the library yourself, and the assembly is where the maintenance cost lives.

Editorial conclusion

Eldora UI fits a design engineer or a small product team that wants finished interface pieces without adopting a component library's runtime and its opinions about styling, and it fits a team that is comfortable owning the copied code. It does not fit a team that wants a versioned dependency with a changelog and security fixes, because the copy and paste model hands you the code and no upgrade path, and it does not fit a project that needs to know which version of a component it is running. Verify three things before you build on it: the licence of the individual components you copy, which the project states as MIT but which you should confirm for any file you take, the React and framework versions the components expect, since a copy carries its own assumptions about the surrounding app, and whether the component registry in the repository is the source of truth for what is currently offered, since the release tags do not tell you that.

Frequently asked questions

Official sources

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