chore: tree-shake date-fns package

[JinCoreana]

Proposed behaviour

Tree-shake dates-fns and reduce bundle size to 252KB

AFTER

Current behaviour

dates-fns includes methods that are not in use to the bundle increasing size to 1.23MB
Open issue: date-fns/date-fns#3004

BEFORE

Checklist

• Commits follow our style guide
• Related issues linked in commit messages if required
• Screenshots are included in the PR if useful
• All themes are supported if required
• Unit tests added or updated if required
• Playwright automation tests added or updated if required
• Storybook added or updated if required
• Translations added or updated (including creating or amending translation keys table in storybook) if required
• Typescript d.ts file added or updated if required
• Related docs have been updated if required

QA

• Tested in provided StackBlitz sandbox/Storybook
• Add new Playwright test coverage if required
• Carbon implementation matches Design System/designs
• UI Tests GitHub check reviewed if required

Additional context

Testing instructions

[edleeks87]

Comment: Carbon is open source, we can't limit these locales here imo, if we did it would need to be a breaking change as well.

[edleeks87]

I think reverting it would address the linting an playwright failures you're seeing as well

[JinCoreana]

Thank you for the comment :)
Now I will check.

• solely limiting methods import? ❌- minor improvement
• downgrading or upgrading date-fns? Downgrade to 2.27.0 ❌- since the primary cause is bundling the entire locales, no improvement / Upgrade ❌ - for the same reason, no improvement but please note: V3 resolved many structural issues and is not compatible withdate-fns-tz yet. open PR: Update date-fns to v3 marnusw/date-fns-tz#265 /
• lazy-loading date-fns? ➖
• consumer side webpack configuration? ➖

[JinCoreana]

Hi @edleeks87
I've looked into your comment about the date locales logic. It seems that Carbon only requires en-GB as the default, which is set in the I18nProvider. If users need different date locales, they'll have to install date-fns and pass it as dateFnsLocale of locale prop to the I18nProvider.

I checked if there is any logic for users to simply pass a locale code, and Carbon automatically uses the related date locale which then would involve bundling all date locales, but I couldn't find anything like that. I understand the failing part of the Playwright tests is for testing the dateFnsLocale that consumer passes from their level so I imported the whole date-fns only in test files as it does not seem to increase the bundle size. Could you confirm if I'm missing something?

[edleeks87]

Hey @JinCoreana thanks for the detailed investigation. We export the locales via Carbon so that projects using it don't also require having date-fns installed. The easiest win here might be to move this out of carbon, add date-fns as a peer dependency and then require consuming projects to import and use the locales they want. We would need to do it as a breaking change so my preference is to leave this file for now and discuss it with the Carbon team as there may well be other changes we'd like to make and it would be better for all that to be bundled together as one new major version imo

[JinCoreana]

I see. Thank you, Ed! Would it be good that we open a new issue for your discussion then?
I will be off next week but I handed over this PR to @AlexKryzh, I will still ask him to explore other approaches like lazy loading or consumer side adjustments to see if we can make improvements in the meantime even with the entire locales in the bundle. We will keep you posted on this. :)

[AlexKryzh]

Thanks @edleeks87 , this was a Miro's team spike ticket of 2-3 days to investigate the best solution.
Can you confirm that Carbon Team prefer to do a refactor? Refactor about don't include all locations and permit to consumers include required locations.
Just for extra info: our next step was to investigate to lazy load this locations.

[AlexKryzh]

@edleeks87 will discuss this changes with the Carbon Team, probably it will be part of breaking change Carbon update.

[JinCoreana]

I have added this index only for playwright wondering date.pw test is flaky because of latency caused by importing the entire locale. So I've configured it to import only the necessary testing locales.

[edleeks87]

If we're no longer going to re-export the date-fns locales we should add it as a peerDependency so consumers have it installed in their own node_modules. I think the commit message should look something like this as well:

fix: ensure that tree-shaking works with date-fns package 

Updates the import paths for `Date` utils to allow tree-shaking to work and a reduction in bundle size.
    
BREAKING CHANGE: Carbon no longer re-exports the `date-fns` locales, consuming projects will need to install the package and use them directly from there.

closes: SBS-84395

[edleeks87]

comment: I'm happy with this change. We'll need to do it as a breaking change though as anyone who's imported from this file will obviously need to update and install date-fns

[nineteen88]

I am content with the changes proposed. I will approve it once we've addressed Ed's comments as I think it's important.

[JinCoreana]

Hello, I am back and caught up with @AlexKryzh
According to his conversation with @edleeks87, this PR is closed as Carbon team will take it over and address this breaking changes. Thank you!
cc: @nineteen88

[nineteen88]

@JinCoreana This has now been merged in the following PR: #6713