ArtPlayer/AGENTS.md

AGENTS.md

Compatibility Refactor

The compatibility modernization plan is maintained in refactor/README.md. For refactor work, read its compatibility contract, task plan, and progress log before editing. Use refactor/tasks.json as the task status source and regenerate the readable plan with node refactor/scripts/plan.mjs --write; validate it with node refactor/scripts/plan.mjs --check. Preserve existing public APIs, event behavior, types, DOM/CSS hooks, and distribution entrypoints. The planned TypeScript migration permits incremental JS/TS coexistence; it does not authorize changing consumer APIs or treating planned validation as completed validation. Apply refactor/quality-contract.md to every implementation task: the user authorizes improving unreasonable internals while preserving old public contracts. Refactor responsibilities and dependencies alongside TypeScript migration, add meaningful risk-based tests, and update package architecture/maintenance documentation in the same change. The user requires one separate local Git commit for each completed refactor task. Include the task ID in the commit subject and include its implementation, tests, documentation, and status updates together. Verify the commit before starting the next task. Do not bundle multiple newly completed tasks or include unrelated work. This does not authorize pushing or publishing. Use Yarn Classic 1.22.22 as packageManager and maintain only the root yarn.lock. Core public declarations are authored in packages/artplayer/public/ and generated with yarn build:types into the existing types/ entrypoints. Do not hand-edit the generated core declarations; yarn check:types is read-only and rejects drift. Use Node from .node-version; frozen Yarn installs and strict toolchain checks are required. Bun remains an isolated evaluation and must not replace Yarn without a new user decision. The user also authorizes installing needed dependencies and adding or improving reasonable project scripts for the refactor without asking again for routine tooling choices. Record their purpose and versions, use the appropriate workspace/dependency category, update the lockfile when applicable, and verify compatibility and reproducible execution. After implementation and its necessary tests, hand off the results and wait for the user to guide and start the review phase. Do not automatically begin REVIEW-01/02/03, including an early first review. Follow refactor/release-reviews.md: the three review rounds and closure of blocking findings remain required before candidate publication. Connected Chrome interaction checks complement committed automated browser tests; neither connection availability nor mocks replace actual playback or required device evidence. If Chrome is unavailable, use the Codex in-app browser for supported real-page tests. The user explicitly authorizes this fallback; record the actual browser/version and limitations. Do not block ordinary browser checks solely on the Chrome extension connection. Each review fix remains a separate task and commit. Revalidate changed candidate contents. The user explicitly includes GitHub CI/CD modernization in this refactor. Follow refactor/github-ci-cd.md for PR checks, regression matrices, artifacts, Pages and npm workflows. Distinguish local configuration from verified remote runs. The user requires every workspace package to move to its own next major version for this refactor (M.m.p -> (M+1).0.0). Follow refactor/version-policy.md; independent versions and old API compatibility remain mandatory. This version policy is not publication authorization.

Project Summary

ArtPlayer is a monorepo for a modern HTML5 video player and its ecosystem packages.

• Homepage: https://artplayer.org
• Local dev site: http://localhost:8082
• API docs: https://artplayer.org/document
• Packaging model: workspace monorepo with per-package versioning and per-package build output

The repository contains:

• packages/artplayer: the core player
• packages/artplayer-plugin-*: UI and playback plugins
• packages/artplayer-proxy-*: proxy renderers and playback adapters
• packages/artplayer-tool-*: helper tools
• packages/artplayer-vitepress: docs site package
• docs/: local demo site, examples, compiled assets, generated docs
• scripts/: custom build/dev/doc tooling

Working Style For This Repo

• Verify the real implementation before editing docs or examples.
• Prefer changing the source package first, then regenerate build artifacts only when needed.
• Keep package APIs small and consistent with existing ArtPlayer plugin conventions.
• Preserve the existing visual and API style of sibling packages instead of inventing a new pattern.
• When touching demo examples, make sure the example still works in http://localhost:8082.
• Do not hand-edit dist/, docs/compiled/, or docs/uncompiled/ unless a build step generated them.
• Desktop editor sources live in packages/artplayer-vitepress/browser/; docs/assets/js/common.js, bootstrap.js, loader.js, mobile.js and packages/artplayer-vitepress/docs/public/main.js are generated with yarn build:site-assets. editor-libraries.ts is generated by yarn build:ts.

Primary Commands

Use the repo scripts rather than ad hoc bundler commands.

Development

yarn dev

Starts the local dev site on port 8082 and interactively selects a package to watch. The selected package is built into:

• docs/uncompiled/<package>/

Production Build

yarn build

Interactive build for one package. Outputs:

• packages/<name>/dist/*.js|*.legacy.js|*.mjs
• copied artifacts into docs/compiled/

Build all packages:

yarn build all

Other Project Scripts

yarn build:i18n
yarn build:ts
yarn build:docs
yarn build:llm
yarn build:test
yarn lint
yarn build:all

Notes:

• yarn lint is read-only; yarn lint:fix explicitly fixes the same source/type/script range.
• yarn ci:check runs strict toolchain/plan/lint/tests; yarn ci:build generates outputs and checks imports.
• See refactor/ci-setup.md for CI and separate Pages deployment; remote activation is tracked separately.
• yarn build:all is expensive; use it when a change truly spans builds/docs/types/lint together.

Useful Local URLs

• Root demo index: http://localhost:8082
• Demo by package/example:
  • http://localhost:8082/?libs=./uncompiled/<package>/index.js&example=<example>
• Docs: http://localhost:8082/document/

For proxy/plugin work, prefer validating on the local demo page rather than reasoning only from source.

Repository Layout

Core package

• packages/artplayer/src/index.ts: player entry
• packages/artplayer/src/player/: playback mixins and player-facing behavior
• packages/artplayer/src/control/: bottom controls
• packages/artplayer/src/setting/: settings panel
• packages/artplayer/src/contextmenu/: context menu items
• packages/artplayer/src/plugins/: built-in plugins
• packages/artplayer/src/utils/: shared helpers, component base classes, DOM utilities
• packages/artplayer/public/: public TypeScript declaration sources
• packages/artplayer/types/: generated public declarations and compatibility documentation

Ecosystem packages

Most ecosystem packages follow this pattern:

packages/<package>/
  src/index.js
  src/*.less        # optional
  types/*.d.ts      # optional but preferred for public APIs
  README.md
  package.json
  dist/*

Demo and docs assets

• docs/assets/example/*.js: runnable browser examples
• docs/assets/ts/*.js: TypeScript demo assets targeted by lint/docs flows
• docs/uncompiled/: dev output
• docs/compiled/: production-copied output
• docs/document/: generated docs content

Architecture Notes

Core player

ArtPlayer composes many subsystems during construction. Common integration points:

• art.template
• art.events
• art.controls
• art.setting
• art.contextmenu
• art.layers
• art.plugins
• art.player

When extending behavior, prefer integrating with these existing systems rather than bypassing them.

Control and setting components

Controls and setting entries are managed through component registries.

Relevant implementation:

• packages/artplayer/src/control/index.ts
• packages/artplayer/src/setting/index.ts
• packages/artplayer/src/utils/component.ts

Important behavior:

• art.controls.update(...) and art.setting.update(...) replace existing entries by name
• art.controls.remove(name) and art.setting.remove(name) are the correct cleanup APIs
• selector-style controls rely on default flags to determine highlighted items

If a plugin conditionally shows UI, it must also clean that UI up when the condition no longer holds.

Plugin shape

Standard plugin/export shape:

export default function somePlugin(option = {}) {
  return (art) => {
    return {
      name: 'somePlugin',
    }
  }
}

Naming conventions:

• package: artplayer-plugin-<name>
• global: artplayerPlugin<Name>
• exported function name should match the global naming convention

Proxy packages

Proxy packages usually return a non-video element or video-like shim and emulate media element behavior for ArtPlayer.

Examples:

• packages/artplayer-proxy-canvas
• packages/artplayer-proxy-mediabunny

When editing proxy packages:

• keep the HTMLMediaElement-like surface coherent
• keep event ordering stable
• treat loadedmetadata, loadeddata, canplay, seeked, waiting, and pause/play semantics carefully
• ensure UI state is updated and cleaned up when source topology changes

HLS / adaptive playback controls

The reference implementation for adaptive selector UI is:

• packages/artplayer-plugin-hls-control/src/index.ts
• packages/artplayer-plugin-dash-control/src/index.ts (SDK 4.x/5.x capability adapter)

If adding HLS-like quality/audio selection elsewhere:

• follow the selector format used there
• derive highlighted items from actual current tracks, not only from mode flags
• avoid stale selectors when changing to streams without the same topology

Build and Artifact Rules

• Always edit source first: core runtime in src/, core declarations in public/; other packages retain types/ until their own declaration source migration.
• Rebuild package artifacts after source changes that should ship.
• Do not treat dist/ as source of truth.
• If a change affects demo behavior, also verify the matching file in docs/assets/example/.

For package-specific builds, the normal flow is:

1. yarn dev and pick the package for fast local iteration
2. validate in http://localhost:8082
3. yarn build and pick the package when ready to update shippable artifacts

Documentation Expectations

If a public package API changes, check whether these also need updates:

• the package README.md
• docs/assets/example/<name>.js
• types/<name>.d.ts
• any generated compiled outputs if you built the package

Keep examples realistic and runnable. Prefer local demo URLs or stable public sample streams.

Code Quality Expectations

• Follow existing plain JavaScript style in the repo.
• Use ASCII unless a file already requires otherwise.
• Match the minimal-comment style of neighboring files.
• Avoid unnecessary abstraction; this codebase generally prefers direct implementation.
• Respect current browser targets:
  • modern build: es2020
  • legacy build: es2015

Validation Checklist

For most package changes, validate as many of these as apply:

• source file lint passes
• local demo page loads
• expected events fire once and in the correct order
• controls/settings render correctly
• cleanup works after restart, source switch, or destroy
• package build succeeds

For playback/proxy changes specifically:

• test initial load
• test play/pause
• test seek
• test switching source or track topology
• test whether UI reflects the actual selected track/quality

Notes Specific To artplayer-proxy-mediabunny

This package now depends on modern mediabunny and supports HLS through mediabunny input handling.

Files to understand first:

• packages/artplayer-proxy-mediabunny/src/index.js
• packages/artplayer-proxy-mediabunny/src/VideoShim.js
• packages/artplayer-proxy-mediabunny/src/MediaBunnyEngine.js
• packages/artplayer-proxy-mediabunny/src/input.js
• packages/artplayer-proxy-mediabunny/src/m3u8.js

Key expectations:

• HLS source detection should happen in input.js
• track selection should use actual pairable audio/video relationships
• selector UI should mirror the behavior of artplayer-plugin-hls-control
• selector cleanup is required when a later source no longer supports the same controls
• avoid duplicate readiness events during load and track switches

When Unsure

Start with the nearest sibling implementation instead of inventing a new pattern:

• control/setting UI: artplayer-plugin-hls-control, artplayer-plugin-dash-control
• proxy behavior: artplayer-proxy-canvas, artplayer-proxy-mediabunny
• component lifecycle: packages/artplayer/src/utils/component.ts

If a change spans source, examples, and packaging, make all three consistent in the same pass.