-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v2.0.0] Remove Carbon dependency #86
Comments
An addendum: this will be a breaking change, so we're talking a major version here. |
Alternatively, we could deprecate the method returning the Carbon instance, and then later remove it altogether... |
Currently we are using Carbon when manipulating dates in the extractors and to define the date of birth in the Citizen model. If we just deprecate the Citizen's method to return a DateTime instance instead of a Carbon instance we are not making that of a difference. Maybe really push for the bigger change and totally lose Carbon. 🤷♂️ |
It would however mean that we could have a smoother transition to getting rid of Carbon without introducing a breaking change out of the blue. Something like v1.3.0 having a new |
I may have misunderstood 😅 When upgrading to a later version we can get rid of Carbon. But until then we can implement another method returning a DateTime instance for a smooth transition. That sounds totally fine 👍 |
As I'm working on the JS/TS/npm port, I'm striving to keep dependencies to a minimum - something that the npm ecosystem is plagued with.
However we ourselves are forcing a dependency on a
DateTime
wrapper library that, no matter how great it is, not all projects will use.PHP's
DateTime
class is fine and we should refactor our date handling to it, includingCitizen
's return type.The text was updated successfully, but these errors were encountered: