# Vidstack Player's default release script publishes to next, and the README badge reads that tag

> Vidstack Player is a TypeScript library of UI components and hooks for building web video and audio players, positioned as the successor to Plyr and Vime and as an alternative to JW Player and Video.js. What the page does not do is print an install command, a version, or a changelog entry.

**vidstack/player** — UI components and hooks for building video/audio players on the web. Robust, customizable, and accessible. Modern alternative to JW Player and Video.js.

- Repository: https://github.com/vidstack/player
- Website: https://vidstack.io
- Stars: 3,688 · Forks: 230
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/vidstack-player

## The release script publishes to next and the two badges read that tag

The root package's release script carries a flag:

```json
"release": "pnpm build && node .scripts/release.js --next"
```

There is a dry run beside it, release:dry, which passes the same flag through. So the default release path for this repository is a prerelease publish, and the README badges are built to match: they read the npm dist-tag next for both packages, with labels written as vidstack@next and @vidstack/react@next.

That is a deliberate choice, and it has a cost for anyone reading the front page. The badge shows the prerelease version, so a visitor cannot tell from it which version the project considers stable. The repository has no GitHub releases to fall back on, and the only version in the tree sits in the private workspace package at the root, name vidstack-workspace, version 1.15.6, private true. A user pinning a dependency has to read the dist-tag rather than the repository to learn what they would get.

## The description names JW Player and Video.js while the body names Plyr and Vime

Two positioning statements sit side by side and they are not the same claim. The repository description calls the library a modern alternative to JW Player and Video.js. The README body calls it the successor to Plyr 3.x and Vime 5.x.

Alternative and successor are different relationships. An alternative is a choice among peers, and naming two commercial or legacy players is a reasonable way to say that. A successor implies replacing something specific, which is why the body pins major versions: Plyr 3.x and Vime 5.x. The page does not say what those projects are at today, or whether the versions named are the current ones, so a reader has to check both projects before deciding whether the claim still holds.

The opening line of the body is its own promise, that you can build and ship a production-ready video or audio player, followed by the adjectives customizable and accessible. Nothing on the page defines which accessibility target it means.

## The workspace declares itself twice, once in syntax nothing here reads

The root package.json carries a workspaces field:

```json
"workspaces": [
  "packages/*"
]
```

And the root also holds pnpm-workspace.yaml. Two declarations of the same thing, in two formats, one of which belongs to a different package manager. The one that is actually enforced is pnpm, in three places: packageManager pinned to pnpm@8.7.0, engines asking for pnpm >=8, and a preinstall guard that runs npx only-allow pnpm, which fails the install under npm or yarn before anything else happens.

So the workspaces field is inert here. It would matter if someone opened the repository with a tool that reads it, and it is one more thing to keep in sync. The packages themselves live under packages/, and the build drives them through turbo with a filter over that path, running three tasks per package: analyze, build and types.

## Four files state a Node version and the narrowest one is a Volta pin

The runtime floor is declared repeatedly. engines asks for node >=18 and pnpm >=8. A volta block pins node 18.17.1, an exact patch release. packageManager pins pnpm@8.7.0 exactly. And a .nvmrc file sits at the root for the version manager that reads it.

So a contributor gets four answers: a floor of 18, a specific 18.17.1, an exact pnpm, and whatever the .nvmrc file contains. The Volta pin and the engines floor are compatible but not equivalent, and the gap between them is eighteen months of Node releases by the look of the version numbers.

The compiler settings are looser in the other direction. typescript is a caret range at ^6.0.0, and the TypeScript native preview compiler is pinned to the beta channel rather than to a version, so the type checker a contributor runs depends on when they installed.

## The only staged check is a formatter, and the type check does the rest

A pre-commit hook runs lint-staged, and lint-staged runs one command:

```json
"lint-staged": {
  "*": "oxfmt --no-error-on-unmatched-pattern"
}
```

That is a formatter applied to every staged file, with unmatched patterns tolerated. There is no lint rule engine in the development dependency list, and no ESLint configuration file at the root. So nothing rejects a commit for a style or correctness rule; the static checking comes from the type checker instead, wired into the validate script as build, format, test and typecheck.

Formatting settings live in .oxfmtrc.json rather than in a prettier or eslint config. The repository is consistent about that choice, since oxfmt also appears in the toolchain through turbo's format and format:check tasks, but a reader arriving from a codebase with ESLint will notice there is no rule layer here at all.

## One history, two files, and a generator that reads commits

The changelog is produced from the commit log. The dependency is git-cliff, the configuration is cliff.toml at the root, and the script writes the result in place:

```json
"changelog": "pnpm exec git cliff --output CHANGELOG.md"
```

Alongside the generated CHANGELOG.md the tree also holds RELEASES.md. Two files describing the same version history, one derived from commits and one maintained by hand, and the page links neither. For a library whose positioning is a successor to two predecessors, the upgrade notes are the interesting part for anyone arriving from Plyr or Vime, and they are not on the front page.

The rest of the root is build tooling: turbo.json for the task graph, a pnpm lockfile, tsconfig.json, a .build/ directory, a .scripts/ directory that holds the release script the root package calls, and an assets/ directory.

## Eight install pages, a separate examples repository, and an examples folder holding one file

The quickstart is a list of links and nothing else. Eight installation pages, one per target: JavaScript, Angular, React, Svelte, Vue, Solid, Web Components and CDN. No command is printed on the page, not even a package name to add, so the first thing a new user does is leave the repository.

The resources section points the same way. A hosted player demo, a repository of media files, a repository of caption files, an icon gallery, and a repository of examples. Four of the five are separate repositories.

Which leaves the examples/ directory inside this repository, where the tree lists one file: a README. The runnable examples live elsewhere, and this repository is the library. That is a defensible split for a package with a build pipeline and a lockfile, but it means nothing in the page shows what the components look like assembled.

The credits name three sponsors, BrowserStack for testing, Vercel for hosting and Mux for streaming. The streaming credit is the informative one: the library plays media, and the page acknowledges that where the video comes from is somebody else's service.

## Conclusion

Vidstack Player fits a team building its own player layout out of components in one of the eight frameworks the page lists, and it does not fit someone who wants a drop-in player with a stable published version today. Check three things before you depend on it. Which npm tag you are pinning, because the default release command publishes to next and the README badges advertise that tag rather than a stable one. Which layout you take, because the choice is between building one from components and using a pre-built one. And where your media comes from, since the library ships the player and not the hosting, with the streaming credit in the page going to a sponsored account.

## FAQ

### How do I install Vidstack Player?

The README links a separate installation page for each of eight targets: JavaScript, Angular, React, Svelte, Vue, Solid, Web Components and CDN. No command appears on the page itself, so a new user has to open the documentation site before adding anything.

### Which npm package should I depend on, vidstack or @vidstack/react?

Both exist. The README badges read the npm next dist-tag for the vidstack package and for the @vidstack/react package, and the repository itself has no GitHub releases. The version in the tree is 1.15.6 in a private workspace package called vidstack-workspace.

### What replaced Plyr and Vime in Vidstack Player?

The README calls itself the successor to Plyr 3.x and Vime 5.x, while the repository description calls it a modern alternative to JW Player and Video.js. The page does not say which versions of those projects are current.

### Does Vidstack Player include video hosting or a streaming backend?

No. It ships UI components and hooks for building a player, and the page credits streaming to a sponsored account from Mux. Media used by the demo lives in separate repositories for media files and captions.

### How is the Vidstack Player changelog produced?

A script runs git-cliff with the cliff.toml configuration and writes CHANGELOG.md, and the repository also carries a hand-maintained RELEASES.md. Neither file is linked from the README.

## Sources

- [Issues](https://github.com/vidstack/player/issues)
- [License: MIT](https://github.com/vidstack/player/blob/main/LICENSE)
- [Project website](https://vidstack.io)
- [README](https://github.com/vidstack/player/blob/main/README.md)
- [vidstack/player on GitHub](https://github.com/vidstack/player)

---

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