feat(react): initial skin scaffolding

[sampotts]

Just for React only at this point. If we're happy with the direction, I'll roll it out to the html side too.

• Add the initial exports for the different use cases for skins.
• Add script to copy CSS to dist (watch and build).
• Move media exports alongside the presets.
• Add new paths to bundle size checks.

Imports would look like this:

import { VideoSkin, Video } from '@videojs/react/video';
import '@videojs/react/video/skin.css';

import { AudioSkin, Audio } from '@videojs/react/audio';
import '@videojs/react/audio/skin.css';

import { BackgroundVideoSkin, BackgroundVideo } from '@videojs/react/background';
import '@videojs/react/background/skin.css';

// ...and for other skins (only minimal for now)...

import { MinimalVideoSkin, Video } from '@videojs/react/video';
import '@videojs/react/video/minimal-skin.css';

import { MinimalAudioSkin, Audio } from '@videojs/react/audio';
import '@videojs/react/audio/minimal-skin.css';

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
vjs-10-demo-react	Ignored	Preview	Feb 13, 2026 10:55am

[netlify]

✅ Deploy Preview for vjs10-site ready!

Name	Link
🔨 Latest commit	2d9e199
🔍 Latest deploy log	https://app.netlify.com/projects/vjs10-site/deploys/698f032be204ee0007de3c87
😎 Deploy Preview	https://deploy-preview-523--vjs10-site.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

📦 Bundle Size Report

Package	Size	Diff		%
@videojs/core	4.00 kB	0 B	░░░░░░░░	0%	✅
@videojs/element	1.60 kB	0 B	░░░░░░░░	0%	✅
@videojs/html	7.40 kB	0 B	░░░░░░░░	0%	✅
@videojs/react	6.94 kB	+416 B	████████	+6.2%	🔺
@videojs/store	1.86 kB	0 B	░░░░░░░░	0%	✅
@videojs/utils	1.87 kB	0 B	░░░░░░░░	0%	✅

Total: 23.67 kB · +416 B · +1.7%

---

Entry Breakdown

Subpath sizes are the additional bytes on top of the root entry point, measured by bundling root + subpath together and subtracting the root-only size.

@videojs/core

Entry	Base	PR	Diff	%
.	1.32 kB	1.32 kB	0 B	0%	✅
./dom	2.68 kB	2.68 kB	0 B	0%	✅
total	4.00 kB	4.00 kB	0 B	0%

@videojs/element

Entry	Base	PR	Diff	%
.	817 B	817 B	0 B	0%	✅
./context	823 B	823 B	0 B	0%	✅
total	1.60 kB	1.60 kB	0 B	0%

@videojs/react

Entry	Base	PR	Diff	%
.	6.53 kB	6.45 kB	-79 B	-1.2%	🔽
./audio	—	243 B	—		🆕
./background	—	36 B	—		🆕
./video	—	216 B	—		🆕
total	6.53 kB	6.94 kB	+416 B	+6.2%

@videojs/store

Entry	Base	PR	Diff	%
.	1.29 kB	1.29 kB	0 B	0%	✅
./html	394 B	394 B	0 B	0%	✅
./react	190 B	190 B	0 B	0%	✅
total	1.86 kB	1.86 kB	0 B	0%

@videojs/utils

Entry	Base	PR	Diff	%
./array	104 B	104 B	0 B	0%	✅
./dom	553 B	553 B	0 B	0%	✅
./events	227 B	227 B	0 B	0%	✅
./function	181 B	181 B	0 B	0%	✅
./object	119 B	119 B	0 B	0%	✅
./predicate	265 B	265 B	0 B	0%	✅
./time	465 B	465 B	0 B	0%	✅
total	1.87 kB	1.87 kB	0 B	0%

---

ℹ️ How to interpret

Sizes are minified + brotli, measured with esbuild.
Package totals are computed as root size + marginal subpath costs.
Subpath marginal cost = (root + subpath bundled together) − root alone.

Icon	Meaning
✅	No change
🔺	Increased ≤ 10%
🔴	Increased > 10%
🔽	Decreased
🆕	New (no baseline)

Run pnpm size locally to check current sizes.

[mihar-22]

Awesome work, thanks for doing this!

[mihar-22]

Are we planning on having vanilla CSS files ready first? I'd assume Tailwind and hand written vanilla only as stop gap if compiler isn't ready. If it is Tailwind first then we can remove these probably and get that side setup.

Thoughts?

[sampotts]

I'm assuming we'd use hand-rolled vanilla CSS files first and then the Tailwind compiled versions come later. Probably a good subject to discuss.

[sampotts]

I assume the docs are going to have to at least use the hand-rolled vanilla CSS unless we want to get back into the vjs prefix stuff we had in tech preview.

[mihar-22]

I guess it depends if we're supporting eject or not in Beta, I don't see it in Sarah's doc so maybe not.

If that's right then starting vanilla makes sense :)

[mihar-22]

Starting vanilla is pretty cool actually because it gives us a real reference to test the compiler against.

[sampotts]

Yeah, I think @cpillsbury was keen to have an "expected CSS" to compare against so that would be the aim 👍🏼

[mihar-22]

CSS watch/copy changes

Replaced the concurrently + chokidar-cli + rsync setup with tsdown's native copy option and a small watch plugin:

• copy — tsdown copies src/**/*.css to dist/{mode} preserving directory structure (replaces rsync + css:copy script)
• watch-css plugin — calls this.addWatchFile() with each concrete CSS file path so rolldown detects changes and triggers a rebuild + re-copy. Necessary because:
  • tsdown's watch config value gets overwritten by CLI --watch flag (resolveWorkspace does { ...config, ...inlineConfig })
  • addWatchFile needs real file paths, not glob patterns
• Removed chokidar-cli and concurrently devDependencies
• Simplified scripts — build is just tsdown, build:watch is just tsdown --watch ./src --no-clean

Tested: CSS changes in src/presets/ propagate to both dist/default and dist/dev during watch mode.