Update date-fns to 2.29.3
#2310
Conversation
PolariTOON
requested review from
JF-Cozy,
Merkur39 and
Ldoppea
as code owners
BundleMonUnchanged files (2)
No change in files bundle size Groups updated (1)
Final result: ✅ View report in BundleMon website ➡️ |
| @@ -22,7 +22,7 @@ const DumbHelloWorld = translate()(({ t, f, lang }) => ( | |||
| <div> | |||
| {t('helloworld')} | |||
| <br /> | |||
| {f('2020-01-06', 'DDD MMM')} | |||
| {f(new Date('2020-01-06'), 'd MMM')} | |||
There was a problem hiding this comment.
Can't, f deal with this BC by itself? It it's a string, then create a new Date() by itself? In order to help the migration.
There was a problem hiding this comment.
Also, is there any codemods that are helping to convert old date notation (ex DDD MMM) to the new one?
There was a problem hiding this comment.
There is this table in the changelog of the lib that compares the old pattern with the new pattern : https://github.com/date-fns/date-fns/blob/main/CHANGELOG.md#200---2019-08-20 . There are sometimes multiple way to convert the pattern, depending on what we really expect.
|
|
||
| const getWarningMessage = lang => | ||
| `The "${lang}" locale isn't supported by date-fns. or has not been included in the build. Check if you have configured a ContextReplacementPlugin that is too restrictive.` | ||
|
|
||
| export const provideDateFnsLocale = (userLang, defaultLang = DEFAULT_LANG) => { | ||
| lang = userLang | ||
| const resolvedDefaultLang = defaultLang === 'en' ? 'en-US' : defaultLang | ||
| const resolvedUserLang = userLang === 'en' ? 'en-US' : userLang |
There was a problem hiding this comment.
This should also be done for fr-FR, right? And also es-ES since these are the 3 supported langages
There was a problem hiding this comment.
French and Spanish localizations have not been moved. They are still in fr and es directory and fr-FR and es-ES do not exist, so we should not change anything for them.
| } | ||
| } | ||
| lang = resolvedUserLang | ||
| return locales[lang] | ||
| } | ||
|
|
There was a problem hiding this comment.
It also means that the consuming app should change the call to <I18n to pass the right ISO code. Today this call is based on what the stack / flagship are injecting. For instance https://github.com/cozy/mespapiers/blob/48b5ec048b00d29c418f06606cc9ec15c2a203c7/src/targets/browser/setupApp.jsx#L15
PolariTOON
force-pushed
the
feat/add-format-locally-distance-to-now-strict
branch
from
01ea93c to
cba770f
Compare
PolariTOON
changed the title
formatLocallyDistanceToNowStrictdate-fns to 2.29.3
PolariTOON
force-pushed
the
feat/add-format-locally-distance-to-now-strict
branch
2 times, most recently
from
f83bcff to
1429f3c
Compare
BREAKING CHANGE: This change expectations on arguments passed to the `f` function returned by the `useI18n` hook. The first one now should be a `Date` object instead of a string and the second one now needs to conform to Unicode Technical Report 35.
`date-fns` does not export any `en` folder anymore, but apps still rely on it via the `I18n` component. We allow them to use either `en` or `en-US` as a locale identifier. This should help consuming libs and apps to migrate.
`date-fns` functions do not accept dates formatted as strings anymore, but only date objects. We make it so the `f` function returned by the `useI18n` hook still accepts other types of values, strings in particular. This should help consuming libs and apps to migrate.
PolariTOON
force-pushed
the
feat/add-format-locally-distance-to-now-strict
branch
from
1429f3c to
0abfcc7
Compare
This is a major update of
date-fnswhich brings breaking changes that will affect libs and apps consuming Cozy UI.