anuraghazra
Issue #764: Add custom year
Add custom year feature as in issue #764
now requesting /api?username=vzsky&year=2021 should work!
Someone is attempting to deploy a commit to the github readme stats Team on Vercel.
A member of the Team first needs to authorize it.
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
Edit as requested. I'm not sure if there's a better way to write the test. Please let me know if you have some advices
@vzsky I checked your PR, and there were still some bugs. I fixed these bugs in eb445fa and af6553e. I made some comments for you to understand why I made these changes. Please review these commits 👍🏻.
One tip: You can run the project locally using the vercel dev command (see https://github.com/anuraghazra/github-readme-stats/blob/master/CONTRIBUTING.md#local-development). Doing this will allow you to debug your code locally using vscode (see https://github.com/vercel/vercel/issues/2864#issuecomment-963533339).
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
9406466) 98.02% compared to head (de4cefa) 96.66%. Report is 18 commits behind head on master.
:exclamation: Current head de4cefa differs from pull request most recent head b60aa8f. Consider uploading reports for the commit b60aa8f to get more accurate results
Additional details and impacted files
@@ Coverage Diff @@
## master #2107 +/- ##
==========================================
- Coverage 98.02% 96.66% -1.36%
==========================================
Files 27 22 -5
Lines 6275 3811 -2464
Branches 549 328 -221
==========================================
- Hits 6151 3684 -2467
- Misses 121 125 +4
+ Partials 3 2 -1
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
![codecov[bot] avatar](https://avatars.githubusercontent.com/in/254?v=4 "Published by a pub.dev verified publisher"){kind=small}
can you assign this issue to me
@Vaibhav-kesarwani this is an already finished pull request which will be merged when it receives enough upvotes or if any of the other collaborators reviews it. I, therefore, am afraid that I can not assign you to the accompanying feature request 😅.
I'm unsure how it can take two years to merge this, but I guess every single of your cards being misleading (showing 13k commits in 2024 when it's been 4 days) isn't enough of a problem?
At least close this PR so someone else can fix it if this fix isn't good enough.
I'm unsure how it can take two years to merge this, but I guess every single of your cards being misleading (showing 13k commits in 2024 when it's been 4 days) isn't enough of a problem?
At least close this PR so someone else can fix it if this fix isn't good enough.
Thank you, @lionkor, for your input. I want to remind everyone that this is a community-driven open-source project, and all contributions are made during our contributors' personal time 😅. We prioritize issues and pull requests based on community interest, as demonstrated in our discussion on GitHub issue #1935. This pull request has garnered significant attention and has already been approved. We're now awaiting one more review before merging. I've contacted @qwerty541, @anuraghazra, @Zo-Bro-23 and @francois-rozet to expedite this for their possible review and feedback 👍🏻. Meanwhile, I greatly appreciate everyone's patience and understanding as we juggle our commitments. Your support and cooperation mean a lot to us!
With that being said, it appears that there are some conflicts that need to be resolved before we can proceed with the merge. Unfortunately, I'm currently facing significant time constraints due to my Master's thesis deadline 😅. Would anyone be able to assist in resolving these conflicts?
I'll sort them out today!
Excellent, thanks for the quick response! After that, we can merge this pull request if any approves it of the other collaborators 👍🏻.
I resolved merge conflict with the main branch. I ended up rewrite many pieces as the repository structure changes significantly since my first commit. It would be great if you could review it again.
I did edit a thing unrelated to the issue
- there is one test that assume current year to be 2023, edited to automatically fetch current year with
new Date()
Also, if I'm not mistaken, currently the card shows totalCommits ({currentYear}) but the data is actually the last year, which is something like since 365 days ago, not since 2024. That might be what @lionkor inputted.
From the wording of the current card, totalCommits(2024) sounds like total commit since Jan2024.
However, I did not edit this.
That is problematic because o a request to /api?username=vzsky&year=2024 will yield exactly the same card, but different (and correct) info on commits of 2024.
Yeah, current behavior seems to be saying current year, but the stat is past one year (365 days) of data, or so
if I'm not mistaken, currently the card shows
totalCommits ({currentYear})but the data is actually the last year.
I see. I would agree to change this to (last year) as for the "contributed to" field.
Maybe last year still implies "last, but not this, year". How about 1 year?
(one year) or (1 year) is fine, but would need to make it uniform.
Anyway, I find myself unable to check whether the feature works or not. I am not a JS dev, and don't get how to render a "dummy" card locally :sweat_smile:
(one year)or(1 year)is fine, but would need to make it uniform.Anyway, I find myself unable to check whether the feature works or not. I am not a JS dev, and don't get how to render a "dummy" card locally 😅
@francois-rozet thanks for reviewing this PR ❤️🔥🚀. I will do the final review, including testing if it works, but your approval will give me the confidence to merge it 👍🏻.
(one year)or(1 year)is fine, but would need to make it uniform.Anyway, I find myself unable to check whether the feature works or not. I am not a JS dev, and don't get how to render a "dummy" card locally 😅
I agree that it should be uniform. I used last year for the contributors count since it was clear that it meant 365 days in the past, especially since the year option will show (2024) etc. Then again, I'm not a native English speaker, so it might be better to change the text 🤔.
Thanks to @francois-rozet for the comments and @rickstaa for offering to do the final review.
I have edited according to the comments from @francois-rozet.
About the display, I think both (last year) and (one year) are fine, but I prefer (one year) a little more. Also, I am also not a native. If there is a consensus then it should be easy to fix the code (and the tests?).
edit: implementation went with last year
Deployment failed with the following error:
The provided GitHub repository does not contain the requested branch or commit reference. Please ensure the repository is not empty.
Fixed as requested, @qwerty541.
Thanks for spotting and reporting my mistakes!
Hi @qwerty541,
I would like to ask if there are any ways to speed up the review of these PRs. This issue has been ongoing for a long time, and I hope it can be resolved because the number of commits doesn't match up. There are even cases where the total number of commits is less than the commits in the current year, which is quite odd!
If there's anything I can do to help, please let me know! Thank you to the development team for your hard work!
2 years in review <3 truly a pinnacle of engineering
just merge it if it works, or find other maintainers.
Hi @qwerty541,
I would like to ask if there are any ways to speed up the review of these PRs. This issue has been ongoing for a long time, and I hope it can be resolved because the number of commits doesn't match up. There are even cases where the total number of commits is less than the commits in the current year, which is quite odd!
If there's anything I can do to help, please let me know! Thank you to the development team for your hard work!
cc @rickstaa