The Video.js v10 repository is now a signpost rather than a source tree

Three files left in the tree

The top level listing is the whole repository now. There is a.github/ directory, a LICENSE file and a README.md. That is it.

The reason is stated in the readme under the heading Where did the files go. The source files have been removed from this repository so nobody lands on stale code. They're still in this repository's git history, and the last full snapshot is a named commit, acd4720.

That is a deliberate and, on balance, considerate decision. A repository that keeps the old source around is a repository where a developer opens a pull request against a tree that is not built, is not tested, and does not merge, and the failure is silent until a maintainer closes the pull request with a link to somewhere else. Deleting the files turns that into an immediate, unavoidable redirect.

The cost is that the repository is no longer browsable as a source of truth for the v10 codebase. Anything you want to read has to come from the git history or from the new repository, and a link to this repository on a blog post now lands on a signpost rather than on code.

The last push was on 2026-10-12, though the repository is explicitly no longer maintained. An abandoned redirect is a worse outcome than a stale tree, because it looks authoritative while pointing nowhere useful.

The history was merged, not left behind

The readme reassures about the history before the routing table, and it is the reassurance that matters for anyone who was reading the old tree.

The full v10 history was merged into the main Video.js repository, so nothing was lost.

That is a different operation from copying the files across. Merging the history means the commits, the branches and the authorship moved with the code, so a blame annotation from the v10 era still points at the right person in the new repository, and a bisect across the transition still works.

The fallback is the git history of this repository, with a named final snapshot at acd4720, which is the commit to check out if you need to see the v10 tree exactly as it was.

For a project that has been shipping v10 for a while, the practical question is whether anything you depend on still exists in the new repository, and the answer the readme gives is that everything is there, with the paths unchanged.

That last point is the one that saves the most work. Most projects that move a monorepo or a major version around change directory paths, and a path change in a build system is a breaking change that reaches every consumer. Here the paths stay the same, which means a branch rebase is mechanical.

The npm packages did not move, and that is the part users care about

There is a short Installing section, and it exists to prevent a panic that would otherwise be entirely reasonable.

The npm packages haven't changed. Keep installing from the same @videojs/* scope, for example @videojs/react. Only the source repository moved.

So the migration is invisible to anyone who only consumes the packages, which is most people. A package.json that says @videojs/react keeps working exactly as before, and there is no new scope to change to, no new package name to remember, and no change to the lock file.

That is a well managed piece of housekeeping. The obvious alternative, publishing the v10 packages under a new scope to mark the move, would have broken every dependent project for no benefit, since the packages are the same code with the same names.

The recent release list shows the scope in action, with several packages published in one go under the @videojs scope alongside the main one, which is the shape of a coordinated release across a family of packages that have to move together.

The routing table, and where each kind of conversation goes

The readme contains a table that maps what you are looking for to where it now is, and it is worth reading as a piece of community management rather than as documentation.

Source code is at videojs/video.js. Bug reports and features go to the issues there. Questions and ideas go to discussions. Pull requests go to the pull requests page. Documentation is at videojs.org/docs. The changelog is the CHANGELOG.md in the main repository. And chat is on Discord.

The separation between issues and discussions is the deliberate part. An issue is a thing that is broken, and a discussion is a question or a proposal, and keeping them apart is what stops a repository's issue tracker from turning into a support forum. Moving a repository and then mixing those two categories would have been a poor start for the new one.

The documentation staying on the website rather than in the repository is also normal, and the link to the changelog rather than to a release page is a choice to have one canonical history.

For the Discord link, it is worth noting that a chat server is the one place where a migration is genuinely painful, because the members of the old channel do not automatically appear in the new one.

What to do with an open issue or a pull request

There is a section for the people who are mid-something when the repository moves, and it is the most practically useful part of the readme.

If you have an open issue or PR here, please re-open it against videojs/video.js. Most local branches should rebase onto the new repository's default branch, with paths unchanged.

The rebase instruction is short because the paths are the same, which is the whole reason the transition was painless for contributors as well as for users. A branch that was opened against the v10 tree applies to the new tree with no file moves to resolve, so the work of a contributor is a rebase and a re-open rather than a rewrite.

There is also a table of contents at the top of the README, listing the sections, and the readme is written in the second person and with a certain amount of politeness, which is appropriate for a document whose job is to be received by someone who has just been told that the thing they were using has moved.

The releases show the scope moving as one

The release history is short and it illustrates the family structure of the packages.

The recent releases are [email protected], @videojs/[email protected] and @videojs/[email protected], all published within a couple of seconds of each other on 2026-10-02.

So the main package and the provider plugins for YouTube and Wistia were versioned and published together, which is the only way a release like that works. A player package and a provider plugin that talk to each other at the protocol level cannot be released independently without a compatibility window, and the fact that they carry the same minor and patch version is the packaging expressing that they are one unit.

The youtube and wistia packages are the interesting ones, because they are the parts of Video.js that embed a third party player, and they are therefore the parts most likely to break when the player underneath changes. Pinning them to the same version as the core package is the arrangement that avoids that.

The v10 major version itself is a consequence of the same thinking, and the readme's insistence that the npm packages have not changed is a promise that a v10 consumer upgrading within v10 sees no change at all.

Why the repository was emptied rather than left to rot

It is worth reading this repository as a case study, because the decision is a small lesson in how a project handles the end of a major version's life.

The alternative was to leave the source in place and add a deprecation banner. That is what most projects do, and it has a predictable outcome. The repository stays the first search result, the first link in every tutorial, and the first place a developer opens. Its contents stop changing, so any documentation that points at it slowly becomes wrong, and nobody notices because the code looks complete.

Removing the files removes the temptation. The repository is still the first search result, but what it contains now is the answer to the question the reader has, which is where the code went.

The licence stays, which matters for the history to remain legally coherent, and the.github/ directory stays.

GitHub cannot classify the licence as a standard one, and the last push on 2026-10-12 shows the redirect is still being touched. The project homepage is videojs.org, and the version 10 line is where the Video.js 10 work ended up.

Editorial conclusion

Treat videojs/v10 as a pointer rather than a project, because it exists only to route people to the main repository, and the source files were deliberately removed so that nobody lands on stale code. If you are upgrading a v10 application, keep installing the same @videojs packages and change where you report problems. Verify first which version your application resolves to from npm, since the packages were not renamed or republished under a new scope, and that any open pull request of yours is reopened against the main repository, because a change against this one will go nowhere.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. videojs/v10 on GitHub