Apply consistent deprecation notices to public Remotion APIs that remain available. Use TypeScript annotations and documentation formatting to mark APIs as no longer recommended, identify replacements, and review whether both representations follow the conventions.
Reference for how deprecation of public Remotion APIs is represented in TypeScript source and documentation. Use when adding, reviewing, or discussing a deprecation of a function, component, hook, type, prop, option, or other public API that remains available.
Review the instructions the agent will receive before you install.
Deprecation of a public API that remains available is represented in three places:
@deprecated annotation on the public TypeScript API.info admonition named Deprecated directly after that heading.These conventions apply to functions, components, hooks, types, props, options, and other public APIs.
The public symbol carries a JSDoc @deprecated annotation. The annotation states the replacement when one exists and may link to its documentation.
/**
* @deprecated Use `newApi()` instead: https://www.remotion.dev/docs/new-api
*/
export const oldApi = () => {};
The annotation belongs where consumers receive it. For a re-export or compatibility alias, this is the exported symbol rather than the non-deprecated implementation.
The deprecated API name in its heading uses double-tilde strikethrough. <AvailableFrom> remains outside the strikethrough.
# ~~oldApi()~~<AvailableFrom v="4.0.0" />
For a prop or option:
### ~~`oldOption?`~~
The frontmatter title remains unchanged. A page that otherwise relies only on its frontmatter title has an explicit struck-through heading.
An info admonition named Deprecated appears directly after the heading and points to the replacement when one exists.
:::info Deprecated
Use [`newApi()`](/docs/new-api) instead.
:::
Runtime warnings, sidebar badges, release notes, removal versions, and removal behavior are not currently standardized as part of API deprecation.
Removed APIs are outside this convention. They may remain documented for migration purposes, but they no longer have a public symbol to annotate.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Add a reported Remotion bug to the bugs API with its affected versions, a short title, and upgrade guidance. Follow the existing entry format and place the new record first so recent bugs appear at the top.
Add a Remotion command-line or configuration option, or convert a hardcoded flag into a shared option definition. Connect parsing, configuration setters, help entries, and generated documentation so the option is consistently available and documented.
Add a new effect to @remotion/effects, including its implementation, package entry points, documentation, interactive demo, and preview images. Follow the package conventions and verify the changes with tests, formatting checks, and builds.
Add a person to the Remotion experts page by placing their portrait, entering their profile and contact links, and generating an expert card image. The instructions specify file locations, profile fields, and how to verify card generation.
Create a new @remotion package within the Remotion monorepo, a repository containing multiple packages. Set up its files, register it across the project, and prepare documentation, usage examples, and build configuration.
Add a new sound effect to @remotion/sfx, from registering the audio file to exporting its URL and documenting its use. The workflow covers playback examples, attribution, navigation entries, waveform generation, and the package build.