-
Notifications
You must be signed in to change notification settings - Fork 131
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
feat(twas): refracto to use intl api #974
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I consider that it is better to keep the current library, since it has been in use for a longer time, has been extensively tested and, therefore, is more stable and reliable.
On the other hand, the library you suggest you just created it recently, exactly one hour ago, which implies that it has not yet been sufficiently evaluated in different scenarios. Also, since Deno is compatible with NPM, it is not strictly necessary to migrate to a library published in JSR unless there is a compelling reason, such as a deprecation or a significant advantage.
That's not right my lib have more test case and 100% test coverage. I'm working on CI that test the package on deno and bun
I agree with you on much of it. But don't forget that SJR's source code represents the entire project. And if it's too dependent on NPM, it's not very serious: a registry that needs another registry to function is “the snake that dies on its own tail”. |
After reviewing the original package alongside your proposed implementation, I've noticed that the way time interval and time difference calculations are handled is very similar to the code found in this repository (the current package used), which is licensed under MIT. The logic and structure are nearly identical, and they even share the same naming conventions and package name—aside from a few added configuration and test files. Could you please confirm whether both codebases have been carefully compared for any discrepancies, and that the proper MIT license attribution is maintained in both cases? This similarity reinforces my earlier point that the changes may not provide a significant improvement or benefit overall compared with current package. |
That just a rewrite in typescript and "modernize". |
I would actually be in favour of not using a dependency, and instead use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DurationFormat (or Duration from temporal) |
I'll try to see how to use Intl |
442a995
to
3721c6e
Compare
), | ||
hours: Math.floor((diff % (1000 * 60 * 60 * 24)) / (1000 * 60 * 60)), | ||
minutes: Math.floor((diff % (1000 * 60 * 60)) / (1000 * 60)), | ||
seconds: Math.floor((diff % (1000 * 60)) / 1000), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't think going into seconds is useful
// Force english because JSR is an English-only project | ||
// @ts-ignore - TS doesn't know about this API yet | ||
const formatter = new Intl.DurationFormat("en", { style: "long" }); | ||
return formatter.format(duration); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return formatter.format(duration); | |
return formatter.format(duration) + " ago"; |
Use intl api instead of dep