Proposal: Move calendar plugins (Hijri, Persian, Buddhist, etc.) to separate packages

[amotarao]

Background

Since v9.14.0, react-day-picker ships the following calendar sub-exports:

• react-day-picker/hijri
• react-day-picker/persian
• react-day-picker/buddhist
• react-day-picker/hebrew
• react-day-picker/ethiopic

To support the Hijri calendar, @tabby_ai/hijri-converter@1.0.5 was added as a production
dependency of the main package.

Concerns

Looking into this package:

• Only 1 version has ever been released (1.0.5)
• Last updated: August 2023 (over 2.5 years ago)
• Weekly downloads before react-day-picker adopted it: under 1,000
• Weekly downloads now: ~600,000 (entirely driven by react-day-picker)

It's difficult to assess the reliability and long-term maintenance of this package. More
importantly, as more calendars are added, users who don't use Hijri are still forced to install
its dependencies.

Proposal

Would it be worth considering publishing each calendar as an independent npm package?

@react-day-picker/hijri
@react-day-picker/persian
@react-day-picker/buddhist
@react-day-picker/hebrew
@react-day-picker/ethiopic

Benefits

1. Isolated dependencies — the main package stays lean
2. Opt-in installation — users only install what they need
3. Transparency — users can evaluate each package's dependencies themselves

Curious to hear your thoughts!

[gpbl]

@amotarao thanks for the detailed write-up! I agree with the direction.

The current setup makes the main package carry calendar specific dependencies even for users who never import those calendars, which isn’t ideal for long-term maintenance.

I think splitting calendars into separate packages is the right path. I’ll open a tracking issue/RFC so we can define the migration details and roll it out safely. I’m also planning to release a v10 soon (mainly to remove old deprecated APIs), and it would be great to include this change in it.