Closed sebastinez closed 12 months ago
All modified lines are covered by tests :white_check_mark:
Comparison is base (
fc312b9
) 96.47% compared to head (d09e29c
) 96.48%.:exclamation: Current head d09e29c differs from pull request most recent head d4e78f2. Consider uploading reports for the commit d4e78f2 to get more accurate results
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Thanks for your reviews, what are the next steps? Do you need me to sign something or can the PR get merged?
Hey folks, this issue doesn't allow me to update fake-timers, since it would break my production. Is there work be done on a better solution? Or is anything holding this PR up?
Didn't want to close the PR, just comment on it
Seems like you just need to implement your own suggestion that iterates over the props 🤩
PS. Nothing should ever prevent you from upgrading. Try the Npm package 'patch-package' next time ✌️
Since there's no compilation step in this repo, you can also depend on your fork directly
I'm getting the same issue, but with Intl.NumberFormat
:( I think sinon would need to pick up the whole Intl API to fix this
edit: ok.. now I see this is actually doing that, so I probably need to wait for a release to happen?
New version is out.
Thanks! Sorry for hijacking this PR 😅
Purpose (TL;DR) - mandatory
PR #474 has introduced a mock for the intl API, and this has introduced a regression for me, where I'm not able to call
Intl.RelativeTimeFormat
.Background (Problem in detail)
The problem showed in some of my test cases, once I updated
fake-timers
, when trying to useIntl.RelativeTimeFormat
I got the following error:Intl.RelativeTimeFormat is not a constructor
Solution
The solution I opted for is to assign
RelativeTimeFormat
to the mockedIntl
API with.