Jerome Fitzgerald

@akolybelnikov I will be looking into this to see if we should handled the `shouldComponentUpdate` or leave it to the implementer. I can think of a scenario where we may...

Sorry this has taken me some time, hoping to make time on Saturday to circle back.

Oh wow! Very cool! Thanks for the hard work and detail @caseybaggz! I was in the process of moving to `prettier` (well, `standard-prettier`) in the beta. However, I can tack...

@leo4ever - I pushed up an update to GitHub :octocat: to help with the development process (eslint, etc.). This is in preparation to cycle through a few options to see...

@leo4ever Didn't want you to think I forgot this. Unfortunately I have some time commitments that are precluding my availability. Perhaps someone else may be able to look into this...

In `0.3.0` we've added some links and more documentation around the available variables.

Thanks for making the time on the latest and greatest. Awesome, work @christopherklint97 ! For the `RangeError` ones `date-fns@3` introduced types to inform the developer that they shouldn't do these...

Aye ... digging into this a bit more if the move to `date-fns@3` types is to accompany. The three places of change are: ### 1️⃣ > `./scripts/build/_lib/typings/formatBlock.js` L114: ```js "import...

**Edited** Synopsis of what may need to be addressed ([Release Notes](https://github.com/date-fns/date-fns/releases/tag/v3.0.0)): - Moved to named exports instead of default - ~~Account for functions that are no longer exported from `date-fns@3`...

The move from `date-fns@2` to `date-fns@3` has introduced 💥 breaking changes 💥. Which is why the authors identified the breaking/major version change and accompanying [release notes](https://github.com/date-fns/date-fns/releases/tag/v3.0.0). - `date-fns-tz@2` out of...