react-mui-multi-range-picker
Multi date range picker for MUI free and pro
- BPM
- 190
- GRADE
- SS
- LEVEL
- 7
- RELEASES
- 6
- YEARS
- 2025–2025
Day One, Version 0.6
The first release of the multi-range picker went out as v0.6.0, with npm already at 0.7.0. The code had been living in an app that needed it before I pulled it out and published it under my own scope, which is how most of my libraries have started.
There were two packages, free and Pro, both live from the first afternoon and both hooked up to codecov and Codacy.
Non-Contiguous Dates, Finally
On October 27, 2025 I started it, published the package and cut a release, all in the same day. MUI's date pickers let you select one range, and I needed several non-contiguous ones, selected by clicking and dragging across a calendar. I couldn't find one, so I built it.
I built it twice. There's a free package on @mui/x-date-pickers, calendar-only, no commercial license needed, for people who just want multi-range selection. And there's a Pro edition on @mui/x-date-pickers-pro with a text input for manual entry and chip-based range management, where each range is a chip with a close button, which needs an MUI X Pro license in production. I split it that way so people who only need drag selection don't need a Pro license.
Over the next twelve days I shipped new versions almost daily as I ran into edge cases in the app that needed it. It ended up being one of the most useful things I made that year.
Getting The Drag Right
v0.9.4 came out forty-eight hours after the first release. I went from 0.6.0 to here in two days because the drag interaction wasn't right yet.
Picking one date range is easy, and MUI already does it. Picking several separate ranges by dragging across a grid raises a lot of questions: what happens when a drag crosses an existing range, whether a click inside a selection removes a day or starts a new range, what a partial drag means when you leave the calendar and come back, and how any of it works on a touchscreen with no hover.
I was releasing both editions together, the free one on @mui/x-date-pickers and the Pro one with chips and text input, so every fix had to land twice and stay consistent across two different pickers. Release automation made that manageable.
Day Four, 0.10.8
Day four, and 0.10.8 went out on npm, a minor bump plus a run of patches since the day before.
I had coverage reporting on every push, a static analysis grade, and the two packages kept in step. By this point the component's shape was mostly settled and the changes were in the details. The free edition stayed a calendar you drag on, and the Pro edition kept its text entry and chips. I always released them together so you could switch between the two without relearning the props.
The Last Minor Bump
November 2, six days in, v0.11.0. This was the last minor version the picker got. After it came 0.11.1 the next day and 0.11.6 on the 7th, and that was it.
After the private work and twelve days of public releases, it did what it was supposed to: let people pick two weeks in March and one in June without fighting the calendar. I left it at 0.11 instead of calling it 1.0.
It's the odd one out in a year I mostly spent on compilers, egui bridges and my own language.