chore(deps): bump date-fns from 3.6.0 to 4.1.0
Bumps date-fns from 3.6.0 to 4.1.0.
Release notes
Sourced from date-fns's releases.
v4.1.0
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
TZDateto v1.0.2 as it includes a bunch of critical bug fixes.Fixed
- Fixed internal
constructFromthrowing an exception onnullarguments. Whilenullisn't allowed, the functions should rather returnInvalid DateorNaNin such cases. See #3885.Added
- Added missing time zone support to
format,formatISO,formatISO9075,formatRelativeandformatRFC3339. See #3886.v4.0.0
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.
Added
Added time zones support via
@date-fns/tz'sTZDateclass andtzhelper function. See its README for the details about the API.All relevant functions now accept the context
inoption, 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,
addDayswill get the current date and time in Singapore and add 5 days to it.startOfDaywill inherit the date type and return the start of the day in Singapore.Changed
The function arguments, as well as
Interval'sstartandend, now can be of different types, allowing you to mixUTCDate,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
inoption or the first encountered argument object type. TheInterval'sstartandendwill be considered separately, starting fromstart.In the given example, the result will be in the
TZDateas the first argument is a number, and thestarttakes precedence over theend.clamp(Date.now(), { start: new TZDate(start, "Asia/Singapore"), end: new UTCDate(),
... (truncated)
Changelog
Sourced from date-fns's changelog.
v4.1.0 - 2024-09-17
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
TZDateto v1.0.2 as it includes a bunch of critical bug fixes.Fixed
- Fixed internal
constructFromthrowing an exception onnullarguments. Whilenullisn't allowed, the functions should rather returnInvalid DateorNaNin such cases. See #3885.Added
- Added missing time zone support to
format,formatISO,formatISO9075,formatRelativeandformatRFC3339. See #3886.v4.0.0 - 2024-09-16
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.
Added
Added time zones support via
@date-fns/tz'sTZDateclass andtzhelper function. See its README for the details about the API.All relevant functions now accept the context
inoption, 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,
addDayswill get the current date and time in Singapore and add 5 days to it.startOfDaywill inherit the date type and return the start of the day in Singapore.Changed
The function arguments, as well as
Interval'sstartandend, now can be of different types, allowing you to mixUTCDate,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
inoption or the first encountered argument object type. TheInterval'sstartandendwill be considered separately, starting fromstart.In the given example, the result will be in the
TZDateas the first argument is a number, and thestarttakes precedence over theend.clamp(Date.now(), {
... (truncated)
Commits
313b902Fix v4.1.0 change log entry26cd336Promote to v4.1.097b53b9Cover time zone edge cases59b7563Add missing time zone support to format, formatISO, formatISO9075, formatRela...0121164Prevent constructFrom from throwing an error on nullbd87ef5Update@date-fns/docs99b4e67Prepare v4.08df1706Rewrite the time zones doce351977Promote to v4.0.0-beta.18523656Fix scripts/test/types.sh- Additional commits viewable in compare view
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
-
@dependabot rebasewill rebase this PR -
@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it -
@dependabot mergewill merge this PR after your CI passes on it -
@dependabot squash and mergewill squash and merge this PR after your CI passes on it -
@dependabot cancel mergewill cancel a previously requested merge and block automerging -
@dependabot reopenwill reopen this PR if it is closed -
@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually -
@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency -
@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) -
@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) -
@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 96.92%. Comparing base (
3c4d860) to head (2621a32). Report is 11 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #5177 +/- ##
=======================================
Coverage 96.92% 96.92%
=======================================
Files 30 30
Lines 3416 3416
Branches 1427 1427
=======================================
Hits 3311 3311
Misses 105 105
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Would be great to have this merged, or just change the version in package.json to "^3.6.0 || ^4.1.0". There are pretty much no breaking changes in v4 and after the upgrade in my app I have both versions bundled.
@balajis-qb Another interesting challenge. This should be pretty simple, but the docs site broke after upgrading the package to V4.
@martijnrusschen, Sure, I'll check.
@martijnrusschen , We are facing an issue as [email protected] defaults to ES Module
In our Rollup js config we marked date-fns and it's sub-packages as external dependencies - it'll skip the date-fns code being added to our generated bundle. It'll be dynamically imported by the browser. But as browser can't natively handle ESM moduls it's breaking. Previously it worked as in v3.6 date-fns didn't use ESM module.
One simple solution is to add date-fns to our bundle, by removing it from external config of rollup.config
Gotcha, I think the tricky part is that including it will increase the bundle size pretty heavily.
Isn't that a problem with the website, not with the library? Presumably the dependencies are eventually bundled, so it's a responsibility of the end user to process them if necessary. Also ESM should actually work in a browser without any transpilation, as long as the <script> tag has type="module" attribute.
Here's a reference to the previous issue which introduced this logic: https://github.com/Hacker0x01/react-datepicker/issues/1606. If we can get this upgrade in without drastically increasing the bundle size, that would be great.
@dependabot rebase
Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry!
If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.
If you change your mind, just re-open this PR and I'll resolve any conflicts on it.