fix(deps): update dependency date-fns to v4

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
date-fns	^2.29.3 → ^4.0.0

---

Release Notes

date-fns/date-fns (date-fns)

v4.4.0

Compare Source

This release revisits the approach to CDN usage and introduces a new package, @date-fns/cdn and deprecates the date-fns CDN scripts. It allowed reducing the zipped package size from 5.83 MB down to 3.96 MB without introducing any breaking changes.

In v5.0.0-alpha.0 where CDN scripts are completely removed from date-fns the change is more significant and brings the zipped package size down to 2.89 MB.

It is just the first step in optimizing the package size. Expect further size reduction in the future v4 and v5 versions.

Changed

• DEPRECATED: The date-fns CDN scripts are now deprecated and will be removed in the next major release. Please switch to the new @date-fns/cdn package for CDN usage.

• Removed CDN source maps to reduce the package size. If you rely on them, please switch to the new @date-fns/cdn package that still includes them.

v4.3.0

Compare Source

Kudos to @​ImRodry and @​puneetdixit200 for their contributions.

Fixed

• Fixed missing modularized optimization fallback (for Next.js and others). See #​4193.

• Fixed pt locale first day of week to be Sunday. See #​4195 by @​ImRodry.

• Fixed zh-CN, zh-HK, and zh-TW locale month parsing for October, November, and December. See #​4194 by @​puneetdixit200.

v4.2.1

Compare Source

Fixed

• Fixed type definitions missing in v4.2.0 due to TypeScript misconfiguration.

v4.2.0

Compare Source

This is a minor release in all senses, it only includes documentation updates (first of many) that points to the new You Don't Need date-fns* page.

* Not really

Changed

• Added Temporal API references to the JSDoc annotations of add, addBusinessDays, and addDays.

v4.1.0

Compare Source

This release adds time zone support to format functions (that I somehow missed when working on the feature) and fixes a few bugs.

Make sure also upgrade TZDate to v1.0.2 as it includes a bunch of critical bug fixes.

Fixed

• Fixed internal constructFrom throwing an exception on null arguments. While null isn't allowed, the functions should rather return Invalid Date or NaN in such cases. See #​3885.

Added

• Added missing time zone support to format, formatISO, formatISO9075, formatRelative and formatRFC3339. See #​3886.

v4.0.0

Compare Source

I have great news! First, ten years after its release, date-fns finally gets first-class time zone support.

Another great news is that there aren't many breaking changes in this release. All of them are type-related and will affect only those explicitly using internal date-fns types. Finally, it has been less than a year since the last major release, which is an improvement over the previous four years between v2 and v3. I plan on keeping the pace and minimizing breaking changes moving forward.

Read more about the release in the announcement blog post.

- Sasha @​kossnocorp

Added

• Added time zones support via @date-fns/tz's TZDate class and tz helper function. See its README for the details about the API.

• All relevant functions now accept the context in option, which allows to specify the time zone to make the calculations in. If the function also returns a date, it will be in the specified time zone:

  import { addDays, startOfDay } from "date-fns";
  import { tz } from "@date-fns/tz";
  
  startOfDay(addDays(Date.now(), 5, { in: tz("Asia/Singapore") }));
  //=> "2024-09-16T00:00:00.000+08:00"

  In the example, addDays will get the current date and time in Singapore and add 5 days to it. startOfDay will inherit the date type and return the start of the day in Singapore.

Changed

• The function arguments, as well as Interval's start and end, now can be of different types, allowing you to mix UTCDate, TZDate, Date, and other extensions, as well as primitives (strings and numbers).

  The functions will normalize these values, make calculations, and return the result in the same type, preventing any bugs caused by the discrepancy. If passed, the type will be inferred from the context in option or the first encountered argument object type. The Interval's start and end will be considered separately, starting from start.

  In the given example, the result will be in the TZDate as the first argument is a number, and the start takes precedence over the end.

  clamp(Date.now(), {
    start: new TZDate(start, "Asia/Singapore"),
    end: new UTCDate(),
  });
  //=> TZDate

• BREAKING: This release contains a bunch of types changes that should not affect the library's expected usage. The changes are primarily internal and nuanced, so rather than listing them here, I recommend you run the type checker after the upgrade. If there are unfixable problems, please open an issue.

• BREAKING: The package is now ESM-first. CommonJS is still supported, and it should not affect most users, but it might break in certain environments. If you encounter any issues, please report them.

Fixed

• Fixed CDN build compatibility with jQuery and other tools that expose $ by properly wrapping the code in an IIFE.

v3.6.0

Compare Source

On this release worked @​kossnocorp and @​world1dan. Also, thanks to @​seated for sponsoring me.

Fixed

• Fixed weeks in the Belarisuan locale's formatDistance.

Added

• Added CDN versions of modules compatible with older browsers. See the CDN guide.

v3.5.0

Compare Source

Kudos to @​fturmel, @​kossnocorp, @​makstyle119, @​tan75, @​marcreichel, @​tareknatsheh and @​audunru for working on the release. Also, thanks to @​seated for sponsoring me.

Fixed

• Fixed functions that use current date internally and made them work with date extensions like UTCDate.

• Fixed daysToWeeks returning negative 0.

• Fixed German grammar for the "half a minute" string.

Added

• Added the Northern Sámi (se) locale.

• Added the constructNow function that creates the current date using the passed reference date's constructor.

v3.4.0

Compare Source

Kudos to @​kossnocorp, @​sakamossan, and @​Revan99 for working on the release. Also, thanks to @​seated for sponsoring me.

Added

• Added roundToNearestHours function.

• Added Central Kurdish (ckb) locale.

v3.3.1

Compare Source

Kudos to @​kossnocorp and @​fturmel for working on the release.

Fixed

• Fixed DST issue in getOverlappingDaysInIntervals, resulting in an inconsistent number of days returned for intervals starting and ending in different DST periods.

• Fixed functions incorrectly using trunc instead of round. The bug was introduced in v3.3.0. The affected functions: differenceInCalendarDays, differenceInCalendarISOWeeks, differenceInCalendarWeeks, getISOWeek, getWeek, and getISOWeeksInYear.

v3.3.0

Compare Source

On this release worked @​kossnocorp, @​TheKvikk, @​fturmel and @​ckcherry23.

Fixed

• Fixed the bug in getOverlappingDaysInIntervals caused by incorrect sorting of interval components that led to 0 for timestamps of different lengths.

• Fixed bugs when working with negative numbers caused by using Math.floor (-1.1 → -2) instead of Math.trunc (-1.1 → -1). Most of the conversion functions (i.e., hoursToMinutes) were affected when passing some negative fractional input. Also, some other functions that could be possibly affected by unfortunate timezone/date combinations were fixed.

  The functions that were affected: format, parse, getUnixTime, daysToWeeks, hoursToMilliseconds, hoursToMinutes, hoursToSeconds, milliseconds, minutesToMilliseconds, millisecondsToMinutes, monthsToYears, millisecondsToHours, millisecondsToSeconds, minutesToHours, minutesToSeconds, yearsToQuarters, yearsToMonths, yearsToDays, weeksToDays, secondsToMinutes, secondsToHours, quartersToYears, quartersToMonths and monthsToQuarters.

• Fixed the Czech locale's formatDistance to include 1 in formatDistance.

• Fixed differenceInSeconds and other functions relying on rounding options that can produce a negative 0.

• Added a preprocessor to the locales API, enabling fixing a long-standing bug in the French locale. (#​1391)

• Added missing yearsToDays to the FP submodule.

• Made functions using rounding methods always return 0 instead of -0.

Added

• Added format alias formatDate with corresponding FormatDateOptions interface.

v3.2.0

Compare Source

This release is brought to you by @​kossnocorp, @​fturmel, @​grossbart, @​MelvinVermeer, and @​jcarstairs-scottlogic.

Fixed

• Fixed types compatibility with Lodash's flow and fp-ts's pipe. (#​3641)

• Fixed inconsistent behavior of roundToNearestMinutes.

Added

• Added exports of format, lightFormat, and parse internals that enable 3rd-parties to consume those.

v3.1.0

Compare Source

This release is brought to you by @​kossnocorp, @​makstyle119 and @​dmgawel.

Fixed

• Fixed the plural form of weeks in Swedish.

Added

• Added yearsToDays function.

• Added a warning about using protected tokens like Y or D without passing a corresponding option. See #​2950.

v3.0.6

Compare Source

On this release worked @​imwh0im, @​jamcry and @​tyrw.

Fixed

• Fixed bug in areIntervalsOverlapping caused by incorrect sorting (#​3614)

v3.0.5

Compare Source

This release is brought to you by @​goku4199.

Fixed

• Fixed internal toDate not processing string arguments properly

v3.0.4

Compare Source

This release is brought to you by @​kossnocorp.

Fixed

• Fixed isWithinInterval bug caused by incorrectly sorting dates (#​3623).

v3.0.3

Compare Source

Fixed

• Rolled back pointing ESM types to the same d.ts files. Instead, now it copies the content to avoid the Masquerading as CJS problem reported by "Are the types wrong?".

v3.0.2

Compare Source

Fixed

• Fixed yet another issue caused by ESM types by pointing to the same d.ts files.

• Added package.json to exports to provide access to tooling.

• Fixed TypeScript 5.4 build break by using the latest type names.

v3.0.1

Compare Source

Fixed

• Fixed an error in certain environments caused by d.mts files exporting only types.

v3.0.0

Compare Source

Changed

• BREAKING: date-fns is now a dual-package with the support of both ESM and CommonJS. The files exports are now explicitly in the package.json. The ESM files now have .mjs extension.

• BREAKING: The package now has a flat structure, meaning functions are now named node_modules/date-fns/add.mjs, locales are node_modules/date-fns/locale/enUS.mjs, etc.

• BREAKING: Now all file content’s exported via named exports instead of export default, which will require change direct imports i.e. const addDays = require(‘date-fns/addDays’) to const { addDays } = require(‘date-fns/addDays’).

• BREAKING: TypeScript types are now completely rewritten, check out the d.ts files for more information.

• BREAKING: constants now is not exported via the index, so to import one use import { daysInYear } from "date-fns/constants";. It improves compatibility with setups that modularize imports like Next.js.

• BREAKING: Functions now don’t check the number of passed arguments, delegating this task to type checkers. The functions are now slimmer because of this.

• BREAKING The arguments are not explicitly converted to the target types. Instead, they are passed as is, delegating this task to type checkers.

• BREAKING: Functions that accept Interval arguments now do not throw an error if the start is before the end and handle it as a negative interval. If one of the properties in an Invalid Date, these functions also do not throw and handle them as invalid intervals.

  • areIntervalsOverlapping normalize intervals before comparison, so { start: a, end: b } is practically equivalent to { start: b, end: a }. When comparing intervals with one of the properties being Invalid Date, the function will return false unless the others are valid and equal, given the inclusive option is passed. Otherwise, and when even one of the intervals has both properties invalid, the function will always return false.

  • getOverlappingDaysInIntervals now normalizes intervals before comparison, so { start: a, end: b } is practically equivalent to { start: b, end: a }. If any of the intervals’ properties is an Invalid Date, the function will always return 0.

  • isWithinInterval now normalizes intervals before comparison, so { start: a, end: b } is practically equivalent to { start: b, end: a }. If any of the intervals’ properties is an Invalid Date, the function will always return false.

  • intervalToDuration now returns negative durations for negative intervals. If one or both of the interval properties are invalid, the function will return an empty object.

  • The eachXOfInterval functions (eachDayOfInterval, eachHourOfInterval, eachMinuteOfInterval, eachMonthOfInterval, eachWeekendOfInterval, eachWeekendOfMonth, eachWeekendOfYear, eachWeekOfInterval, eachYearOfInterval) now return a reversed array if the passed interval’s start is after the end. Invalid properties will result in an empty array. Functions that accept the step option now also allow negative, 0, and NaN values and return reversed results if the step is negative and an empty array otherwise.

• BREAKING: intervalToDuration now skips 0 values in the resulting duration, resulting in more compact objects with only relevant properties.

• BREAKING: roundToNearestMinutes now returns Invalid Date instead of throwing an error when nearestTo option is less than 1 or more than 30.

• BREAKING: IE is no longer supported.

• BREAKING: Now all functions use Math.trunc rounding method where rounding is required. The behavior is configurable on a per-function basis.

• BREAKING: Undocumented onlyNumeric option was removed from nn and sv locales. If you relied on it, please contact me.

• BREAKING: Flow is not supported anymore. If you relied on it, please contact me.

• BREAKING: The locales now use regular functions instead of the UTC version, which should not break any code unless you used locales directly.

Added

• All functions that accept date arguments now also accept strings.

• All functions now export options interfaces.

• Now functions allow passing custom Date extensions like UTCDate. They will detect and use the arguments constructor to generate the result of the same class.

• eachMonthOfInterval, eachQuarterOfInterval, eachWeekOfInterval, and eachYearOfInterval now accept the step option like most of the eachXOfInterval functions.

• A new interval function that validates interval, emulating the v2 interval functions behavior.

• differenceInX functions now accept options and allow setting up roundingMethod that configures how the result is rounded. Math.trunc is the default method.

v2.30.0

Compare Source

Kudos to @​kossnocorp and @​Andarist for working on the release.

Changes

• Fixed increased build size after enabling compatibility with older browsers in the previous release. This was done by adding @​babel/runtime as a dependency. See more details.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

COMPARE TO master

Total Size Diff 📉 -620 Bytes

Diff by File

Name	Diff
packages/account/package.json	📉 -1 Bytes
packages/console/package.json	📉 -1 Bytes
packages/core/package.json	📉 -1 Bytes
packages/experience/package.json	📉 -1 Bytes
pnpm-lock.yaml	📉 -616 Bytes

[github-actions]

This PR is stale because it has been open 10 for days with no activity. Remove stale label or comment or this will be closed in 5 days.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot can't review bot-authored pull requests automatically. A user with Copilot access can request a review manually.

[Copilot]

Copilot can't review bot-authored pull requests automatically. A user with Copilot access can request a review manually.

[Copilot]

Copilot can't review bot-authored pull requests automatically. A user with Copilot access can request a review manually.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (2)

packages/core/package.json:58

• This is a major-version jump (v2 → v4) and is likely to include breaking changes. It would be safer to do this in two steps (v2 → v3 → v4) or at least confirm/adjust call sites for any known breaking API changes introduced across majors before merging, to avoid runtime or build-time regressions.

    "date-fns": "^4.0.0",

packages/console/package.json:68

• Since multiple packages depend on date-fns, consider centralizing the version to avoid drift (e.g., via a workspace-wide override/resolution in the repo root, or using a workspace protocol if your package manager supports it). This reduces the chance of packages unintentionally diverging on different majors/minors over time.

    "date-fns": "^4.0.0",

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (1)

pnpm-lock.yaml:13397

• The lockfile change for the git-hosted oidc-provider dependency drops the integrity field. Keeping the integrity hash helps protect against unexpected tarball content changes and improves install reproducibility; since the tarball URL is unchanged, the previous integrity value can be retained.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (1)

pnpm-lock.yaml:13397

• The lockfile change for the git-hosted oidc-provider dependency drops the integrity hash and replaces it with gitHosted: true. This reduces supply-chain verification/reproducibility compared to the previous lock entry (the tarball URL alone is weaker than a pinned integrity hash). Consider restoring the integrity field (or regenerating the lockfile in a way that preserves it) so installs remain fully verifiable.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

• Files reviewed: 4/5 changed files
• Comments generated: 2
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

react-day-picker@8.10.2 in the repo declares a date-fns peer range of ^2.28.0 || ^3.0.0, which conflicts with the proposed date-fns@4.x upgrade and should be resolved before merging.

Review details

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (1)

packages/console/package.json:68

• This bumps date-fns to v4, but react-day-picker@8.10.2 (used by this package) declares a peer dependency of date-fns: ^2.28.0 || ^3.0.0 (see pnpm-lock.yaml:14126-14130). With date-fns@4.x, installs may produce peer-dep warnings and react-day-picker may be incompatible at runtime; consider upgrading react-day-picker to a version that supports date-fns@4, or keep date-fns within the supported peer range for this package.

    "date-fns": "^4.0.0",

• Files reviewed: 4/5 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

This is a major-version upgrade (v2 → v4) of a widely-used date library, which can introduce subtle runtime/import/formatting behavior changes that require full test/verification before safe approval.

Review details

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

• Files reviewed: 4/5 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The update introduces an unsupported peer-dependency pairing (react-day-picker@8.10.2 expects date-fns ^2.28.0 || ^3.0.0, but the lockfile resolves it with date-fns@4.4.0).

Review details

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (2)

packages/console/package.json:69

• This package depends on react-day-picker@^8.10.2, which (per the lockfile) only supports date-fns ^2.28.0 || ^3.0.0 as a peer dependency. Bumping date-fns here to ^4.0.0 will leave react-day-picker with an unsupported peer, so either upgrade react-day-picker to a version compatible with date-fns@^4 or keep date-fns at ^3 for this package.

    "classnames": "^2.3.1",
    "clean-deep": "^3.4.0",
    "date-fns": "^4.0.0",
    "dayjs": "^1.10.5",

pnpm-lock.yaml:27156

• react-day-picker@8.10.2 declares a peer dependency on date-fns ^2.28.0 || ^3.0.0, but the lockfile now resolves it with date-fns@4.4.0. This will produce a peer-dependency mismatch (and may break at runtime if react-day-picker relies on v2/v3 export semantics). Consider upgrading react-day-picker to a version that supports date-fns@^4, or keep date-fns at ^3 for the console package until the picker can be upgraded.

• Files reviewed: 4/5 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Resolve the incompatible react-day-picker@8.10.2 and date-fns v4 peer dependency.

Review details

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (2)

packages/console/package.json:68

• packages/console still uses react-day-picker@8.10.2, whose peer dependency (pnpm-lock.yaml:14126-14130) only allows date-fns ^2.28.0 || ^3.0.0. Resolving that component with date-fns@4.4.0 creates an unmet peer dependency and leaves the calendar on an unsupported combination (and can fail strict peer-dependency installs); please either keep this package on date-fns v3 or upgrade react-day-picker to a release that supports v4 and adapt its API as needed.

    "date-fns": "^4.0.0",

pnpm-lock.yaml:3989

• react-day-picker@8.10.2 declares date-fns: ^2.28.0 || ^3.0.0 as its peer (see pnpm-lock.yaml:14126-14130), so resolving this peer to 4.4.0 violates the package's supported range. Keep the console on a supported date-fns major or upgrade react-day-picker to a version that supports v4 before taking this dependency bump.

• Files reviewed: 4/5 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The updated lockfile pairs react-day-picker@8.10.2 with date-fns@4.x even though react-day-picker’s peer range only supports date-fns ^2.28.0 || ^3.0.0.

Review details

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (2)

packages/console/package.json:68

• Updating console to date-fns ^4 introduces a peer-dependency mismatch with react-day-picker ^8.10.2 (its peer range is ^2.28.0 || ^3.0.0), which can lead to install warnings and potential runtime/type incompatibilities.

    "date-fns": "^4.0.0",

pnpm-lock.yaml:27156

• react-day-picker@8.10.2 is locked against date-fns@4.4.0 here, but react-day-picker declares a date-fns peer range of ^2.28.0 || ^3.0.0 (see pnpm-lock.yaml:14128-14130). This is an out-of-range peer pairing and may break at runtime or during type-checking.

• Files reviewed: 4/5 changed files
• Comments generated: 0 new
• Review effort level: Lite