coreui / coreui-pro / 36921018362

96%

main: 94%

push

github

fix(Calendar): treat a week row as the ISO week that holds most of its days (#1513)

* fix(Calendar): treat a week row as the ISO week that holds most of its days

With firstDayOfWeek other than 1 a row spans two ISO weeks, and four
places answered "which week is this row" on their own: the number came
from the row's last day, a pick from its first day, a week given as
startDate from its Monday, and the limits from the row's first day. So a
Sunday-first row from August 30 to September 5, 2026 showed 36 and
picked 2026W35, the value given back selected another row, and with
Tuesday to Thursday first a maxDate of 2026W36 disabled week 36.

A row now stands for the ISO week of its middle day, the one that holds
most of its days. getWeekRowDate gives the row's first day in that week
(its Monday when the row starts on Friday to Sunday), which is what a
click or a hover picks; isWeekSelected and isWeekInRange compare rows by
ISO week, so any date of a week, typed or given, selects its row; and
convertToLimitDate moves minDate and maxDate to that day of their week,
so the week of a limit stays selectable. With firstDayOfWeek 1 nothing
moves, except that the week of a minDate later than its Monday can now
be picked, as the month, quarter or year of a limit already can. The
date field compares a week the same way, so it accepts what the calendar
picks.

* chore: raise the unminified JS budgets for the week row change

Measured with gzip -9 against v6-dev, the week row change adds 645 B to
coreui.bundle.js, 627 B to coreui.esm.js and 646 B to coreui.js (most of
it the JSDoc of the new utils) and 152-156 B to the minified bundles.
The three unminified files went over their ceilings, so each moves up to
keep at least 0.25 kB of room: 168.75, 157.5 and 158.75 kB.

* fix(Calendar): widen week limits outward and open on the selected week's row

convertToLimitDate moved minDate and maxDate to the row date of their
week in both directions, so with firstDayOfWeek 1 a m... (continued)

6707 of 7255 branches covered (92.45%)

Branch coverage included in aggregate %.

60 of 60 new or added lines in 3 files covered. (100.0%)

11830 of 12124 relevant lines covered (97.58%)

1422.68 hits per line