@formkit/auto-animate ships one ESM entry and a subpath per framework

main and module both point at index.mjs, so there is one shipped entry

Installing @formkit/auto-animate version 0.10.0 gives consumers one file to load. package.json sets `main` and `module` to the same path, `index.mjs`, with types from `index.d.ts`, and the package declares `"type": "module"`. Nothing else is routed: there is no CommonJS field, no UMD bundle and no separate browser build.

That single entry sits behind framework specific subpaths. The exports map in package.json lists `./vue`, `./preact`, `./react`, `./solid` and `./marko`, and each one resolves `types` to its own `index.d.ts` next to an `index.mjs` for `import` and `default`. A Vue application and a React application therefore load different files from the same package.

The structure explains why the README can claim one line of code works with Vue, React, Solid or any other JavaScript application. The animation engine is shared and the framework binding is a thin file at a subpath, not a separate package to install. The consequence for you is that bundler resolution is part of the setup: nothing in the manifest offers a fallback for a CommonJS consumer.

yarn, npm and pnpm all resolve to the same package name

The install step is the whole of the getting started path:

# yarn
yarn add @formkit/auto-animate
# npm
npm install @formkit/auto-animate
# pnpm
pnpm add @formkit/auto-animate

All three produce the same package, so your choice of manager changes nothing about what runs. The scoped name matters for the import line: the package is `@formkit/auto-animate`, not `auto-animate`, and the framework subpath is a second segment on top of it.

Inside the repository the story is different, because development is pnpm only. The root holds `pnpm-lock.yaml`, `.npmrc` and `.npmignore`, while the docs site lives in `docs/` and is driven by the `dev` and `build-docs` scripts, both of which run vite from that directory. A Nuxt playground sits under `build/nuxt-playground` and is started with `nuxi dev build/nuxt-playground`, which is how the project gets a server rendered case to work against. Contributors install from the lockfile; users pick whichever of the three commands above they already use.

The zero-config claim ends where the documentation site begins

The README makes a specific promise: zero config, drop-in, one line of code. It then stops. Usage instructions, examples and plugin instructions are all links into https://auto-animate.formkit.com, at the anchors `#usage`, `#examples` and `#plugins`.

What that leaves unstated is the part engineers usually want before they commit. The README names no duration, no easing or timing function, no option names at all, and no way to turn the animation off for one component. The zero-config framing is an accurate description of the setup cost, not a description of the surface area, and the two get conflated easily.

The practical consequence is that the README cannot answer the question you will ask next. If your team needs a specific duration, needs to disable motion for a subtree, or needs to know which plugin applies to your framework, the repository has no answer for you and the documentation site is the only source. Read that site before wiring it into a product with a motion design system, because a project with no documented options is also a project with no documented exit.

The release script publishes through build/build.mjs, not npm publish

package.json carries `"private": true`, which normally blocks publishing, yet the release script is `bumpp && node ./build/build.mjs --publish`. Version bumps come from bumpp and the upload runs inside the project's own build script, so the published artifact is whatever that script decides to send. The plain build path is `node ./build/build.mjs`, and `rollup.config.js` at the repository root is where the bundling is configured.

Two TypeScript configs sit side by side: `tsconfig.json` for the package and `tsconfig.marko.json` for the Marko path, with `marko.json` next to them. Marko is not an afterthought, since `./marko` has its own entry in the exports map.

If you fork this, the release path is the first thing you will trip over. Nothing here is the standard `npm publish` flow, and `.npmignore` plus `.npmrc` decide what leaves the directory. Confirm what the build script packages before you publish a fork under the same name.

Playwright runs a leak check and a visual check on the same suite

End to end coverage goes through Playwright, configured in `playwright.config.ts` at the root. `test:e2e` runs the suite, `test:e2e:headed` and `test:e2e:ui` cover the same tests in a visible or driven browser, and `playwright:install` calls `pnpm exec playwright install` to fetch browsers.

Two of the scripts encode what the project considers a defect in animation work. `test:e2e:leak` sets `LEAK_STRICT=1` and filters to memory cases under the chromium project, so leaking listeners or observers across a re-render fails the run instead of passing quietly. `test:e2e:visual` sets `VISUAL=1` and filters to cases prefixed `Visual:`, which is how a changed transition shows up as a broken snapshot.

Both filtered runs are pinned to the chromium project. If you change how elements are observed, that is the command that will tell you whether you have introduced a leak, and it is the reason to run `test:e2e:leak` rather than the default suite before shipping a binding change.

The release list jumps from 0.8.2 to v0.10.0 after more than two years

Three releases are visible in the project's history. `0.8.1` shipped on 2023-11-06, `0.8.2` on 2024-04-10, and `v0.10.0` on 2026-07-10. The last push to the repository is also on 2026-07-10, so the current version and the current work are the same event.

The gap is the interesting part. Between April 2024 and July 2026 nothing was tagged, and the version jumped two minor numbers when work resumed. Version numbers therefore tell you very little about behaviour here. A lockfile pinned to 0.8.2 is missing everything released as v0.10.0, and the jump in minor version suggests the two are not drop-in equivalents, although the README does not document what changed.

What you can lean on is narrower and clearer: MIT licensed, authored by Justin Schroeder, one package, one published entry file. If the pace of releases matters to your decision, check the commit history around 2026-07-10 rather than reading the version number.

Keywords name Angular and Svelte, the exports map does not

The keyword list in package.json covers animation, transition, react, preact, vue, angular, svelte, solid and marko. The exports map routes subpaths for Vue, Preact, React, Solid and Marko. Angular and Svelte appear in the discovery metadata without a matching subpath in the visible exports map.

That gap is the practical limit on the promise of working with any other JavaScript application. For Vue, React, Solid, Preact or Marko the manifest gives you a file to import and a declaration file to type-check against. For Angular or Svelte, the manifest gives you the generic `index.mjs` entry and no framework binding, and the README says nothing about how the generic path behaves in either framework.

So before you commit an Angular or Svelte codebase to this package, the question to answer is whether the plugins page at https://auto-animate.formkit.com#plugins documents an adapter for your framework. If it does not, you are relying on the framework agnostic entry with no documented guidance for it.

Editorial conclusion

Take @formkit/auto-animate when you want transitions in an interactive single page app and you are willing to read the documentation site before relying on timing, plugins or framework bindings. Leave it alone if you need a documented set of options in the README, a CommonJS build, or a steady release cadence, since the manifest is ESM only and the release list jumps from 0.8.2 in April 2024 to v0.10.0 in July 2026. Verify three things before adopting it: which subpath your framework actually imports, what the plugins page says about duration and easing, and whether the documentation site you are reading matches the version in your lockfile.

Frequently asked questions

Official sources

1. formkit/auto-animate on GitHub
2. License: MIT
3. Project website
4. README
5. Releases