react-native-calendars: pure JS month grids that ship TypeScript source and take locales from LocaleConfig

Pure JS means no linking step and no platform dialog either

The library declares itself pure JavaScript with no native code required, which is why the install is a single line and why it works under Expo and CRNA without ejecting. Nothing is registered with the autolinker, so there is no pod step for consumers and nothing to break when a new React Native release reshapes the bridge. The cost is that no part of the widget is handed to iOS or Android. What you render is a React component you style, measure and test yourself, down to the grid, the month header and the swipe between months. That split is a good deal for an app that already owns a design system, and a poor one if you expected the system date sheet to appear after a single call. Adding it and wiring a first press takes two steps:

$ yarn add react-native-calendars

Running the bundled sample is the one place CocoaPods still shows up, because the repository carries an ios/ directory for the example app rather than for the library:

$ git clone [email protected]:wix/react-native-calendars.git

$ cd react-native-calendars

$ yarn install

$ cd ios && pod install && cd ..

$ react-native run-ios

The entry point is src/index.ts, so your own toolchain compiles the dependency

package.json sets main to src/index.ts and types to src/index.d.ts, so what npm hands you is TypeScript source rather than a finished build. Your app transpiles it, and the only build script in the scripts block belongs to the repository, not to the people depending on it. Two consequences follow. First, your TypeScript and Babel configuration decides whether this dependency compiles at all, so a project already fighting strict settings will discover the problem here and blame the calendar. Second, the version field in the repository's package.json reads 1.22.0 while the published releases are numbered 1.1314.0, 1.1313.0 and 1.1312.1. Copy that number out of the file and you pin something far behind the current release, so read versions from the npm registry page instead and keep the lockfile honest.

Date math, row recycling and month swipes are three other people's packages

The runtime dependency list is short and every entry has a job. xdate 0.8.0 does the arithmetic behind the month grid, recyclerlistview 4.0.0 backs the long list that makes a scrollable calendar usable, react-native-swipe-gestures 1.0.5 handles the swipe between months, memoize-one 5.2.1 sits alongside them, and lodash plus prop-types cover object and argument handling. The split keeps the grid itself small, but each of those is a second package that has to keep working with your React and React Native versions, and none of them is optional at runtime. Check the resolved versions in your lockfile before you start debugging calendar code.

LocaleConfig is yours to type, and the README snippet closes its fence mid object

The README's locale example has you assign an entry into LocaleConfig.locales yourself, supplying monthNames, monthNamesShort and dayNames for the 'fr' key. The snippet under Configuring the locale shows the gap: it opens the object, fills three arrays, and stops after dayNames with the closing fence right there, with no closing braces and no value for a date format or a first day of the week. It also imports LocaleConfig twice, on the first and third lines, so pasting it as written will not parse. Nothing else in the file fills in the missing keys. A calendar that has to open on Monday, or print 01/03/2012 instead of a month name, gets no guidance here and has to come from the official documentation site.

Every date is a bare day string, so times and zones never enter the model

Watch how dates cross the boundary. markedDates is keyed by strings such as '2012-03-01' and '2012-03-02', onDayPress hands you an object whose dateString carries the same shape, and current takes the same value. No hours, no minutes, no offset appear anywhere in that surface, and xdate is the only date library in the dependency list. A booking screen, a shift planner or anything with a 09:00 slot therefore has to keep the time part of the model outside the calendar and join it back after a day press. The examples index also advertises a date loading indicator, but the heading sits there empty, so how you are meant to feed days in from a server is not written down in this file at all. Decide the join between your records and the date string before you build the screen, and exercise it across a daylight saving change.

The example screens link out to a private repository, which hides Agenda

The file tells you to check the example screens, and the link resolves to wix-private/wix-react-native-calendar rather than to the public wix/react-native-calendars repository you cloned. The contributors link drifts the same way, pointing at wix/react-native-calendar-components. The fastest route to a finished screen runs through a link whose repository name suggests it is not public. That gap bites hardest on Agenda: it is exported in the first import line next to Calendar and CalendarList, it closes the examples index, and no code for it appears anywhere in the file. If the agenda pattern is what you came for, and it is the part that genuinely needs a data source, then its props and item shape have to be recovered from the official documentation site or from your own experiments. Budget for that, or begin with the plain Calendar where the examples here are complete.

The contributing rules forbid formatting while Prettier config sits in the root

The repository root carries .prettierrc.json, .prettierignore and .eslintrc.js, and the contributing section still closes by asking you not to format files so the syntax stays unified and review stays fast. An editor that formats on save will produce a pull request that violates the rule before anyone reads a line of it. The rest of the workflow is spelled out: yarn test runs yarn lint and yarn unit, lint covers src/ and example/src over .tsx, .ts and .js, and separate scripts drive end to end runs through detox.config.js, performance measurement through reassure and release automation. The last push landed on 2026-10-17 and the project is not archived, with 1.1312.1 released 2025-05-26, 1.1313.0 on 2025-06-24 and 1.1314.0 on 2026-01-29. The stretch between the last two tags is months wide, so diff the tags before assuming a fix landed in a newer number.

Editorial conclusion

Choose react-native-calendars when the calendar is a designed part of your own React Native screen, when you intend to style every cell yourself, and when the platform picker will not do. Pass on it if your model needs hours and time zones, if you need the agenda behaviour documented somewhere you can actually open, or if your build refuses to transpile a dependency whose entry point is src/index.ts. Check three things in your own project before committing: that your Babel and TypeScript settings accept a package shipping source, that your lockfile pairs recyclerlistview and xdate at the versions this release expects, and that the date strings you store match the YYYY-MM-DD shape the component reads.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wix/react-native-calendars on GitHub