CodeVetter · Repo Unpack · Contributor handoff
iamkun/dayjs
Begin with the factory, utilities, constants, and the implementation/declaration/test trio for the target API. Preserve immutable defaults, calendar-versus-elapsed arithmetic, and plugin delegation order. Tests and CI were inspected, not executed, and any later validation must distinguish configured checks from observed results. This brief is a bounded source investigation; it neither establishes exhaustive coverage nor authorizes build, installation, or release actions.
- For core changes, read dayjs construction, parseDate, init, wrapper, and prettyUnit first; these determine accepted inputs, cached state, metadata propagation, and case-sensitive shorthand such as M versus m.
- Preserve ES6 and the repository's ESLint conventions: no statement semicolons or trailing commas, extensionless imports, and existing allowance for parameter reassignment; CONTRIBUTING recommends lint and semantic commit messages.
- Keep default immutability and month-end clamping intact; regression cases already compare January 31 month changes and leap-day year changes with Moment, while badMutable deliberately has different semantics.
- Before changing plugin composition, inspect both issue2027 installation-order suites and the captured old-method chains; a plugin's $i marker prevents installing that same function again with different options.
- Treat timezone and UTC as one edit boundary: tests install UTC first, offset-adjusted valueOf governs instant identity, and regression cases separate host DST from target DST. Do not extrapolate conversion coverage to all calendar arithmetic.
- Update matching declarations for public API changes and preserve locale header/name conventions; declaration tests check existence only, and runtime locale callbacks can be richer than the string-only relativeTime declaration fields.
- Under a later execution-authorized task, start with test-tz or test-tz-plugin for timezone changes, then broaden to npm test and lint; distribution changes also have build/babel and size checks. None of these commands was executed during this investigation.
- Edit source and declaration inputs rather than generated distribution files, inspect build filesystem operations before running them, and use README/source/tests for local onboarding because the English detailed docs are relocation notices; publishing is controlled by the separate master release workflow.