Libraries.dev: three React effect packages and the sites that demo them
High-crafted UI libraries for AI agents: Border beam, Orbs, Metal, Gooey, Image
At a glance
- What is it?
- Jakub Antalik's monorepo ships border-beam, liquid-gooey and thinking-orbs as separate npm packages, each with its own demo site, its own build script and its own deploy target. The interesting part is not the effects. It is how the publishing, hosting and history are wired.
- Who is it for?
- Adopt this if you want a single npm package for one specific effect and you are willing to accept that the packages are published per GitHub release and the demo sites are the primary documentation. Do not adopt it if you need a maintained component set with a stable API surface across versions, because the README describes three unrelated effects rather than a design system.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Three npm packages, not one component library
The repository publishes three libraries: border-beam for an animated border beam, liquid-gooey for liquid morph and move effects, and thinking-orbs for dotted thought-orb loaders. Each is installed on its own (npm install border-beam, npm install liquid-gooey, npm install thinking-orbs) and each has a dedicated demo site on a subdomain of jakubantalik.com. There is no umbrella package that re-exports all three. If you want two of the effects, you add two dependencies. That is a deliberate shape rather than an oversight: the repo layout puts one folder per npm package under packages/, and the README notes that each package owns its own README and LICENSE because npm renders the readme from the package directory rather than the repo root. The audience is React developers who need one visual effect and do not want to pull in a larger component framework to get it.
What the monorepo layout actually buys you
The top level splits into packages/ (published libraries) and sites/ (one demo site per library). npm workspaces means a single npm install at the root covers every package and every site. The README states that both sites alias the library to its source, so editing a library hot-reloads its site with no rebuild step. That is the concrete benefit of keeping demos in the same repo as the code they demo: the feedback loop on an animation tweak is a file save rather than a build and a publish. It also means the demo site is not a snapshot of a released version. It runs against whatever is on your branch, so a demo that looks correct locally can differ from what a user gets from npm.
Running a demo locally and building a package
The README gives the commands directly. Install once at the root, then start the demo you want: npm run dev -w @sites/beam, npm run dev -w @sites/gooey, or npm run dev -w @sites/orbs. Building is per target: npm run build:beam, npm run build:gooey, npm run build:orbs for a single library, and npm run build:site-beam, npm run build:site-gooey, npm run build:site-orbs for a library plus its site, which the README says is what CI does. npm run typecheck covers every workspace. Node is pinned to 20 through a .node-version file, and the README explains why: it matches the version the GitHub workflows use, and Cloudflare's default is older. If you fork this and deploy to Cloudflare Pages, that pin is the difference between a build that matches CI and one that quietly runs a different runtime.
Publishing is per package and triggered by a GitHub release
The README states that publishing runs through publish.yml and executes npm publish -w <package>, triggered by a GitHub release. Two releases are listed in the repository metadata: v1.3.0 on 2026-07-02 and v1.2.0 on 2026-06-09. The version tags are not namespaced by package, which is worth noting if you track changelogs: a tag like v1.3.0 does not tell you which of the three packages moved, and the README does not describe a per-package versioning scheme. If you depend on all three, you will need to check the npm registry for each one rather than reading the repo's release list.
Three sites, three hosting paths, one CNAME file
The deploy setup is the part most likely to confuse someone who forks this. beam.jakubantalik.com runs on GitHub Pages through .github/workflows/deploy.yml, and its domain binding lives in sites/beam/public/CNAME. gooey.jakubantalik.com and orbs.jakubantalik.com run on Cloudflare Pages, built with npm run build:site-gooey and npm run build:site-orbs, output to sites/gooey/dist and sites/orbs/dist. libraries.dev is also Cloudflare Pages but static, with no build command, output sites/home, and its backend is api.libraries.dev, a Worker in a private repository called libraries-pro that is not part of this repo. The README is explicit that only the beam site carries a public/CNAME, because that file is a GitHub Pages mechanism, and that the Cloudflare-hosted sites bind their domain in the Pages project instead. The DNS record itself lives at the registrar, not Cloudflare, since jakubantalik.com is not on Cloudflare's nameservers. One operational note in the README is easy to miss and costs time: Cloudflare's Retry deployment replays the same commit rather than fetching the branch tip, so a build that failed on an outdated commit keeps failing until you push a new one.
The thinking-orbs history problem
thinking-orbs entered this repository through git subtree, so its full commit history is present but the paths are wrong for the new location. The README says those commits touched src/ rather than packages/thinking-orbs/src/, which means git log -- packages/thinking-orbs stops at the merge. To read the real history you have to start from the commit the merge names, for example git log --oneline 9c6d5c3 -- ports/ios/PillsDemo/Sources/PillsApp.swift, or use git log --follow packages/thinking-orbs/src/index.ts. This is a genuine cost for anyone doing archaeology on that package. Blame and log on the other two packages behave normally. The same package also carries native ports under packages/thinking-orbs/ports, a React Native package and a SwiftUI package, kept in step with the web renderer by golden vectors in spec/. The README states plainly that neither native port is published yet, so they are source you can read and copy rather than dependencies you can install.
Where this is the wrong tool
The material describes three visual effects and the machinery around them. It does not describe an API reference, a props table, browser support, bundle size, or accessibility behaviour for any of the three packages. If your requirement is a documented component library with a compatibility policy, this is not it. The demo sites are the documentation, which means learning the API means reading the source or the demo code. There is also a licensing wrinkle worth checking yourself: the repository is MIT, but the README says each package owns its own LICENSE file, and npm renders the readme from the package directory rather than the repo root. I cannot confirm from the supplied material that the per-package licence files are identical to the root licence, so verify the file inside the package you install. On the alternative side, the obvious comparison is a general animation library such as Framer Motion or GSAP, where you compose effects yourself from primitives. The difference in approach is the opposite of this project's: those give you a general system and you build the beam, the gooey morph or the orb loader; Libraries.dev gives you the finished effect and nothing else. If you need five related effects that share timing and easing conventions, a general library will fit better than five separate packages. If you need exactly one effect and want it to look right without designing the motion, the narrower package is less work.
Editorial conclusion
Adopt this if you want a single npm package for one specific effect and you are willing to accept that the packages are published per GitHub release and the demo sites are the primary documentation. Do not adopt it if you need a maintained component set with a stable API surface across versions, because the README describes three unrelated effects rather than a design system. Before installing, read the README inside the package directory you intend to use (npm renders that one, not the repo root), and confirm the licence file that ships with that package.
Community notes