Eva.js splits a PixiJS engine into optional plugin packages

The core is four concepts, everything else is a package

Eva.js describes itself as a front-end game engine for interactive game projects, and its design rationale is one sentence: thanks to the ECS, that is Entity Component System, structure, you can expand your needs through highly customizable APIs.

The core package `@eva/eva.js` is correspondingly small. It holds Game, GameObject, Component, System and Resource. That is the entire runtime you get before adding anything else, and the rendering system is not in it. `@eva/plugin-renderer` is the PixiJS core renderer, listed as a separate package, so even drawing requires a decision.

The performance claim is inherited from PixiJS, which the README names as the efficient runtime and rendering pipeline that makes it possible to unleash the full potential of your device. The repository topics list `canvas2d` and `webgl` alongside `pixijs`, so PixiJS is doing the graphics work and Eva.js is the entity and system layer above it.

The consequence for a new project is that "install Eva.js" is not the decision. The decision is which packages your game needs, and several of them have obvious defaults you will end up taking anyway. That is a design with a real bill attached, and it is worth seeing before you commit.

The published npm package is `@eva/eva.js`, with a bundlephobia size badge and download count badge in the README header.

Rendering coverage is broad enough that the choice is which format your assets are in

The renderer plugins are listed as a table of package names, and reading it is the fastest way to judge whether Eva.js fits your existing art.

Raster and vector: `@eva/plugin-renderer-img` for image rendering, `@eva/plugin-renderer-graphics` for vector graphics drawing, `@eva/plugin-renderer-sprite` for sprite sheet rendering, and `@eva/plugin-renderer-tiling-sprite` for tiling sprites.

Text comes in three flavours in one package, `@eva/plugin-renderer-text`, described as Text, HTMLText and BitmapText. Having HTML text inside the render pipeline is unusual and matters for projects with prose-heavy UI.

Skeletal animation is covered three ways, which is a real differentiator: `@eva/plugin-renderer-spine` for Spine, `@eva/plugin-renderer-spine36` for Spine 3.6 specifically, and `@eva/plugin-renderer-dragonbone` for DragonBones. `@eva/plugin-renderer-lottie` adds Lottie for animation exported from design tools. `@eva/plugin-renderer-sprite-animation` does frame animation.

The effects and utility plugins are where the list gets long: `@eva/plugin-renderer-mask` for mask and clipping, `@eva/plugin-renderer-nine-patch` for nine-slice scaling, `@eva/plugin-renderer-mesh` for perspective mesh deformation, `@eva/plugin-renderer-filter` for PixiJS 2D filters described as blur, colorMatrix, displacement, noise and alpha, `@eva/plugin-renderer-render-texture` for a Phaser-style dynamic render texture, and `@eva/plugin-renderer-dom-element` to pin an HTML element to a GameObject transform.

Two newer entries handle media and world data: `@eva/plugin-renderer-video` renders an HTML5 `<video>` element, and `@eva/plugin-renderer-tilemap` supports a 2D tilemap with a Phaser v1 format and a Godot-style chunked v2.

One plugin is architecture rather than graphics: `@eva/plugin-worker` runs Eva.js inside a Web Worker using OffscreenCanvas, which is the escape hatch if your game blocks the main thread.

Game logic is also packages, so the baseline you install is smaller than you expect

Everything a game needs beyond drawing is opt-in, and the package names are drawn from several engines, which tells you the intended mental model.

Time and animation: `@eva/plugin-transition` for tween animation, `@eva/plugin-tween` for a Godot-style tween with sequence, parallel and yoyo, `@eva/plugin-animation-track` for multi-track keyframe animation, and `@eva/plugin-easing` with shared easing functions covering linear, quad, cubic, elastic, back and bounce. Two tween packages plus an easing package is a hint about how much overlap the maintainers tolerate in exchange for matching different vocabularies.

State and flow: `@eva/plugin-state-machine` is a finite state machine driven by signals, `@eva/plugin-trigger` is described as the stateless cousin of StateMachine mapping signals to declarative actions, `@eva/plugin-signal-bus` is a namespaced global event bus, and `@eva/plugin-evax` is global state management. `@eva/plugin-behavior-script` adds Godot-style scriptable behaviors.

Input and camera: `@eva/plugin-renderer-event` for touch and pointer events, `@eva/plugin-input-action` for an InputActionMap mapping raw key, mouse and touch input to semantic action signals, `@eva/plugin-camera2d` for a 2D camera with follow, deadzone and shake, `@eva/plugin-parallax` for camera-driven background parallax with optional tiling, and `@eva/plugin-path-follow` to move a GameObject along a waypoint path once, on loop or pingpong.

Physics, timing and reuse: `@eva/plugin-matterjs` wraps Matter.js, `@eva/plugin-tick` is a reliable frame scheduler with requestAnimationFrame and a wall clock fallback, `@eva/plugin-timer` is a Godot-style countdown or interval timer, and `@eva/plugin-pool` is a GameObject pool with scene-scoped recycling. `@eva/plugin-hitarea` gives trigger-style overlap detection, described as a Godot Area2D equivalent with no physics.

Then the interface layer: `@eva/plugin-ui` is a UI kit with shapes, 14 `@pixi/ui` widgets and a RadioGroup, `@eva/plugin-a11y` handles accessibility, and `@eva/plugin-ai` is a DOM AI overlay described as a semantic mirror of GameObjects. `@eva/plugin-stats` is a performance monitor and `@eva/plugin-persistence` syncs localStorage with `mx.store`.

None of that is in the core. A minimal Eva.js game with movement and collisions installs the core, the renderer, a sprite or image plugin, input or event handling, and a tween package before it moves a single pixel.

Monorepo tooling shows what a v2 rewrite costs

The root `package.json` is where the v2 status is visible, and it is worth reading because the version field is not a release tag.

It declares `"private": true`, `"workspace": "packages"`, a name of `eva.js` and a version of `2.1.0-beta.8`. So the repository root tracks a beta of the 2.1 line while the tags list shows v2.0.1 from 2026-04-21 and, before that, v1.2.8 from 2022-09-29. The default branch is `v2`, so the branch you get by default is the beta line and the last 1.x release is nearly four years old.

The build is a bespoke script rather than a standard bundler CLI. `prebuildDev` and `buildDev` run `node ./scripts/build.js` with `-d`, and the production variants add `-p -t`, with `prebuildProd` building `spine-base` first because the other spine packages depend on it. `build` runs both dev and prod. Release is `node ./scripts/release.js`, and `scaffold` is `node ./scripts/scaffold.js`.

Testing is layered, which is a good sign for a rewrite. `test` is `jest --runInBand`, while `test:all` calls `bash ./scripts/test-all.sh` and takes arguments, so `test:core`, `test:plugins` and `test:renderer` run separate suites against `packages/`. There are also `test:watch` and `test:coverage` modes, and `ci` runs `lerna bootstrap && npm run cov`.

The API surface is documented from source rather than by hand, with `api-extractor.json`, `typedoc.json` and an `api` script running `api-documenter markdown -i temp -o docs/api`.

Two configuration files describe the code style, `.eslintrc` and `.prettierrc`, alongside `.editorconfig`. Development runs through Vite against the `examples/` directory with `vite ./examples -c ./examples/vite.config.ts`, so the examples double as the integration test bed. There is a `CLAUDE.md` at the root, a `README_CN.md` alongside the English README, and a lockfile in `pnpm-lock.yaml` even though the scripts reference lerna bootstrap.

Where Eva.js is the wrong choice

The clearest wrong case is a project that needs a complete stack on day one. A dozen plugin installs before the first sprite is drawn is a legitimate cost for a large game with clear requirements, and a tax on a prototype with two entities and a moving square. Engines with batteries included exist precisely for that second case.

The second is 3D. The repository topics list `webgl` and `canvas2d`, every renderer plugin in the table is 2D, and there is no scene graph, camera or material system for 3D in the package list. `webgl` in the topics refers to PixiJS's renderer, not to a 3D pipeline.

The third is a team that needs a stable published API today. Working on the `v2` branch means depending on a beta line. That is fine for a hobby project and uncomfortable under a delivery date, particularly with a v1.2.x line that stopped in 2022 between the two.

A fourth consideration is plugin count versus plugin stability. The package table mixes plugins that look like years-old core functionality with entries described in terms of other engines, such as Godot-style and Phaser-style. Eva.js appears to be growing its feature surface deliberately against other engines' vocabularies, which is good for migration and means some packages will be less settled than others. Check the specific plugins you depend on rather than the engine as a whole.

Licensing is not a concern: MIT, with a LICENSE file at the repository root, and the npm packages follow the repository.

Editorial conclusion

Adopt Eva.js if you are building a 2D browser game and want an ECS structure with PixiJS rendering plus ready components such as sprites, spine, tilemap, tweens, state machines and signal buses, installable one at a time. Skip it if you need a 3D pipeline, a physics-first design or a framework with a stable 1.x API surface, because the repository's default branch is `v2`, the root package version reads 2.1.0-beta.8, and the last tag before the beta run was v1.2.8 from 2022-09-29. Before you commit, confirm which generation you are targeting, since the v1.2.x line and the current `v2` branch differ in package layout, and expect to assemble more of the stack yourself than with a batteries-included engine, because even tweening, camera and input are plugins rather than core.

Frequently asked questions

Official sources

1. eva-engine/eva.js on GitHub
2. License: MIT
3. Project website
4. README
5. Releases