# Itshover ships icons as shadcn registry JSON, and carries three different license answers

> An animated React icon set built on motion, installed either through a shadcn registry URL or by copying a component out of the icons directory. The repository metadata, the license section, and the feature list disagree about the license, and the check script runs no tests.

**itshover/itshover** — Icons that move with intent

- Repository: https://github.com/itshover/itshover
- Website: https://itshover.com
- Stars: 2,678 · Forks: 163
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/itshover-itshover

## Three answers to the license question, in three files

Pick any two and they agree. The Apache-2.0 field in the repository's licensing metadata says so, and the license section at the bottom of the README points at the same Apache 2.0 file. Against that, the feature list describes the project as MIT licensed and community owned, and `package.json` carries `"license": "MIT"`. So the answer depends on which file a reader happens to open, and the two that a licensing tool would read, the metadata field and the manifest, do not match each other.

This is not a cosmetic mismatch. Anyone vendoring the icon source into a product needs to know which text applies to the code they copied, and a MIT line in a manifest is the kind of thing that gets quoted in a compliance answer without anyone opening the license file. The project also states it is community owned in the same bullet as the MIT claim, and nothing else in the tree explains what that phrase is meant to cover. Resolve it with the maintainer before the icons end up in something you ship.

## The registry is the product, and the npm package is private

There is no package to install, and the manifest says so plainly with `"private": true`. What ships instead is a shadcn registry, and the documented install is a single command:

```bash
npx shadcn@latest add https://itshover.com/r/[icon-name].json
```

The URL shape tells you how it is produced. The build script named `registry:build` runs a generator over the icons, then `shadcn build`, then formats `registry.json` and the `public/r` directory, which is where those per-icon JSON files land for the site to serve.

The version story is looser than that. The manifest says `0.1.0` and has apparently not moved, while the newest published release is `0.2.0`, described only as new icons added. The two releases are also named inconsistently, one with a v prefix and one without. Since consumers fetch JSON over HTTP rather than resolving a semver range, nothing breaks from that drift, but there is no version anywhere in the install path you can pin.

## Two install paths, two different shapes of ownership

The manual route asks for one dependency and then a copy:

```bash
npm install motion
```

After that you take a component out of the `icons/` directory and import it, with the example given as:

```tsx
import GithubIcon from "@/icons/github-icon";

export default function Example() {
  return <GithubIcon className="h-6 w-6" />;
}
```

That import path assumes a path alias your project has to define, since nothing in a fresh project maps `@/` to anything. The sizing in the example, `h-6 w-6`, is Tailwind, which matches the stated stack of Tailwind CSS 4 with Next.js 16 and React 18 or newer.

The two paths differ in what you end up holding. The registry route pulls a JSON payload through the shadcn CLI and writes files into your project, which means the tool decides the layout. The manual route means you choose where the file lives and you are responsible for the dependency. Both routes end with source in your tree, which is the point of the project, and both make updating an icon a manual merge rather than a version bump.

## The documented animation trigger is hover, and nothing else is

The contribution pattern is three rules: an SVG wrapped in a React component, an animation triggered on hover using motion/react, and an export with ref forwarding for imperative control. That last rule is the interesting one. Ref forwarding is what lets a caller drive the animation from outside the component, and it is the only mechanism in the project's own description that reaches anything other than a pointer hover.

What is absent is as informative. There is no mention of touch input, no keyboard focus state, and no statement about respecting a reduced motion preference, in a library whose entire premise is movement on interaction. The feature list claims every icon animates on interaction and that the icons are designed to move with intent rather than decoration, which leaves the non-pointer case undefined.

On a device with no hover, either the animation never runs or the component falls back to something, and which one happens is decided per icon by whoever wrote it, not by the library. If your users are on phones often enough for that to matter, open two or three icons and read them before committing to the set.

## npm run check runs lint, formatting, and types, but no tests

The development section advertises five commands, and one of them is the aggregate:

```bash
# Install dependencies
npm install

# Start dev server
npm run dev

# Build for production
npm run build

# Format code
npm run format

# Run all checks
npm run check
```

`npm run check` expands to `npm run lint && npm run format:check && npm run typecheck`, which is ESLint, a Prettier check, and `tsc --noEmit`. There is no test script anywhere in the manifest and no test runner in the development dependencies, so the command described as running all checks runs no tests. For a set the README puts at 186 plus icons, that is the state of verification: types and formatting are enforced, behaviour is not.

The stated categories the set covers are UI essentials such as arrows, checks, and navigation; social marks including GitHub, Twitter, Discord, and LinkedIn; tech marks for Docker, Node.js, Python, and TypeScript; actions like copy, send, cart, and settings; currency marks including Bitcoin, Ethereum, Dollar, and Rupee; and status marks for alerts, notifications, and loading states. The 186 figure is a claim in the README, and nothing in the tree counts the icons.

## React 19 type definitions against a React 18 floor

The runtime floor and the type definitions disagree. `react` and `react-dom` are both declared as `>=18.0.0`, while the development dependencies pin `@types/react` and `@types/react-dom` at `^19`. A consumer on React 18 therefore gets components checked against React 19 types, which is exactly the combination that turns a missing or renamed prop into a type error that looks like a bug in the icon.

The rest of the stack is pinned more conventionally. Next.js sits at `16.1.0` with `eslint-config-next` at the same version, motion at `^12.23.26`, Tailwind at `^4` with its PostCSS plugin, TypeScript at `^5`, and Prettier at `^3.7.4` with the Tailwind class sorting plugin. The site also carries `@vercel/analytics` and `@vercel/speed-insights`, and the README carries a Vercel open source badge.

One more thing the manifest reveals: the application that serves the registry is not a static export. It depends on `mongoose` and `axios`, and the tree has a `models/` directory. The icon components need neither, so that coupling belongs to the site rather than to the icons, but it does mean the JSON your CLI fetches is produced by a Next app with a database client behind it.

## The repository is also a working site, with agent rules and an architecture note

What sits in the tree explains why a small icon library has this much machinery. Alongside `icons/`, `components/`, `app/`, `lib/`, and `public/` there are `actions/`, `scripts/`, `constants.ts`, `components.json` for the shadcn setup, `next.config.ts`, `postcss.config.mjs`, `eslint.config.mjs`, two tsconfig files, and a `.cursor/` directory. There is also `ARCHITECTURE.md` and a separate `CONTRIBUTING.md`, so the reasoning behind the layout lives outside the README.

Identity details are consistent across those files: the manifest names the author as Abhij, the README credits `@abhijitwt`, and the social link points at a different handle, `@itshoverr`. The default branch is `master`, and the last push on the branch is 2026-07-23, with the most recent release dated 2026-02-13, so the releases trail the working tree by several months. The README closes by pointing at a Contributor Code of Conduct, which participants are said to agree to by taking part.

The practical read is that this is a site first and a library second. What you install is a JSON file produced by that site, so its availability is a dependency of your build in a way a normal package version is not.

## Conclusion

Itshover is worth a look if you already use Tailwind and motion and want source you own rather than a package you depend on, and the registry route is the better of the two installs because it gives you a file you can read before it lands in your tree. It is not a library to reach for if you need a published package, a documented API surface, or a test suite, because none of those exist here. Before you commit to it, settle three things yourself: which license actually governs the files, since three answers are on offer, what the icons do on a touch device, since the only documented trigger is hover, and whether you are willing to own 186 copies of the same animation pattern.

## FAQ

### How do you install Itshover icons into a React project?

Two ways. Through the shadcn CLI with npx shadcn@latest add pointed at the per-icon JSON URL on itshover.com, or manually by installing motion, copying a component out of the icons directory, and importing it. The manual example imports from an alias such as @/icons/github-icon and sizes the component with Tailwind classes, so both the alias and Tailwind are assumed to exist in your project.

### Do Itshover hover animations work on touch devices?

The project does not say. Its contribution pattern specifies one trigger, hover, driven through motion/react, plus an export with ref forwarding for imperative control, and that ref is the only documented way to drive an animation from outside. Touch input, keyboard focus, and reduced motion preferences are not addressed anywhere in the project's own description, so read the specific icon before relying on it on a phone.

### What license applies to Itshover icons?

The project gives more than one answer. The repository metadata and the license section at the end of the README both say Apache 2.0, while the feature list calls the project MIT licensed and the package manifest declares MIT. Ask the maintainer which text governs the icon source before vendoring it into something you distribute.

### Is Itshover available as an npm package?

No. The manifest is marked private, so there is nothing to install from a registry, and no dependency name is given. Icons arrive as JSON through the shadcn CLI or as source you copy, which is why the build script generates a registry file and formats a public directory for the site to serve from.

## Sources

- [itshover/itshover on GitHub](https://github.com/itshover/itshover)
- [License: Apache-2.0](https://github.com/itshover/itshover/blob/master/LICENSE)
- [Project website](https://itshover.com)
- [README](https://github.com/itshover/itshover/blob/master/README.md)
- [Releases](https://github.com/itshover/itshover/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/itshover-itshover