nullable-new-params

Convert new internal optional parameters to required nullable values in TypeScript diffs.

57.9k|4.4k|Updated Jun 23, 2020
One-click install
npx skills add https://github.com/remotion-dev/remotion --skill nullable-new-params
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nullable-new-params
Source: https://github.com/remotion-dev/remotion/tree/main/.agents/skills/nullable-new-params
Command: npx skills add https://github.com/remotion-dev/remotion --skill nullable-new-params

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires bun, and includes scripts (resource) components.

What problem does it solve?

In the Remotion monorepo, new optional parameters and type members (foo?: T) in internal APIs force callers to make implicit choices, hide absence behind undefined, and break nullable checks when falsy values like 0 or '' are valid. This Skill enforces a strict convention: internal contracts must use required nullable types (name: T | null) so every caller passes an explicit value.

Core Features & Use Cases

  • Diff Scanner: Runs a Bun script that parses git diff output and flags newly added optional members, parameters, and methods in TypeScript files.
  • Public vs Internal Classification: Guides you to determine whether a candidate is exported from a package entrypoint or documented in packages/docs/docs (keep optional) versus an internal helper (convert to required nullable).
  • Refactoring Workflow: Provides concrete before/after patterns for type members, function parameters, and call-site updates, including how to handle public API boundaries with backwards-compatible overloads.
  • Use Case: A contributor opens a PR adding a new frozenFrame?: number prop to an internal component. Use this Skill to scan the diff, classify the prop as internal, refactor it to frozenFrame: number | null, update all call sites to pass null explicitly, and verify with focused tests.

Quick Start

Scan my current diff for newly added optional parameters and convert any internal ones to required nullable values.

Frequently Asked Questions about nullable-new-params

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How to enforce required nullable parameters in TypeScript code reviews

Run the diff scanner script to identify new optional members, then refactor internal types from `name?: T` to `name: T | null`. Update every call site to pass `null` explicitly and replace truthy checks with `value !== null` comparisons to preserve valid falsy values.

Optional vs nullable parameter TypeScript best practice

Use `name?: T` only for public APIs where requiring the value would be breaking. For internal contracts, prefer `name: T | null` so callers make an explicit choice and absence is distinguishable from valid falsy values like `0` or `''`.

How to detect new optional parameters in a git diff

Use the bundled Bun script that parses unified diff output and matches patterns like `field?:` and `method?(`. It scans TypeScript files only and reports file paths, line numbers, and the offending code for each candidate.

Why use null instead of undefined for absence in TypeScript

Null provides a single explicit sentinel for absence, while undefined can leak in from optional chaining, missing object properties, or uninitialized variables. Using `T | null` makes the contract explicit and prevents accidental truthy checks that treat `0` or `''` as absent.

When to keep optional parameters in public APIs

Keep optional parameters when the type is exported from a package entrypoint, listed in package exports, or documented in `packages/docs/docs`. Making such fields required would break existing consumers, so resolve to a concrete internal nullable value at the API boundary instead.