chore: add usage trend

[cwtuan]

Hi, I’d like to suggest adding a dynamic NPM downloads trend image to the README of faker-js. This image would visually highlight the growth in popularity of the package over the past 3 years, helping new users see that the package is actively maintained and gaining popularity.

As a maintainer of npm-compare.com, a platform offering insights into NPM package trends, I believe this PR could give potential users more confidence in adopting faker-js for their projects. It provides a clear and real-time view of the package's increasing usage.

If there are any additional features from npm-compare.com that could further benefit the faker-js project, I’d be more than happy to implement them as well.

Thank you for considering my suggestion. I look forward to your feedback and the opportunity to contribute to this awesome project!

[netlify]

✅ Deploy Preview for fakerjs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	77d502f
🔍 Latest deploy log	https://app.netlify.com/sites/fakerjs/deploys/67b06033bd4b380008f51a66
😎 Deploy Preview	https://deploy-preview-3374.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.97%. Comparing base (7c749b6) to head (77d502f).
Report is 1 commits behind head on next.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #3374      +/-   ##
==========================================
- Coverage   99.97%   99.97%   -0.01%     
==========================================
  Files        2811     2811              
  Lines      216965   216965              
  Branches      941      940       -1     
==========================================
- Hits       216914   216912       -2     
- Misses         51       53       +2     

see 1 file with indirect coverage changes

[xDivisionByZerox]

Thank you for your contribution! The addition of the usage trend feature is a good idea to provide insights into the popularity of the package. However, I have a few points for discussion:

1. The first thing I noticed was the sheer size of the embedded image. We already have several badges at the top of the README for tracking and providing various stats. Such a large image feels out of place and overwhelms the user, in my opinion.
2. Related to the previous point: I'm not sure if the README file is the best place for this information. It might be helpful on npmjs.com, although they themself already provides these information on the sidebar. We identified that users looking at the README on GitHub are usually already interested and want a quick overview of the potential solutions this package provides or how the API is used. I could see such a statistic being relevant or at least nice addition to our documentation, perhaps to fill the more or less empty roadmap page?
3. Can you tell me for how long you have been having the website? I've heard of similar websites like npmtrends or npm-stat before. I've never heard of your website. This is not meant to be an insult but like you are saying in your own argument: seeing the way a service is addopted by the community has direct influence on the decision of others thinking whether to adapt as well.
4. One more thing: I noticed that your website does not seem to be GDPR compliant since you are using Google Analytics without an explicit opt-in mechanism.

Please let me know what you think about my concerns.

[ST-DDT]

Do you have a GitHub repo/issue tracker as well?
I would like to provide some feedback.

[matthewmayer]

If this is not an official NPM project i think you are supposed to request permission from npm, Inc first to use "npm" in your product name.

https://docs.npmjs.com/policies/logos-and-usage

[ST-DDT]

@cwtuan Could you please respond to the above questions?

[cwtuan]

Thank you for your thoughtful feedback and for considering my contribution!

1. I really appreciate your patience. I’ve been in communication with npm Inc. recently, and I’m happy to let you know that I’ve obtained permission to use the “npm” name in my website. This should clear up any concerns about the branding of the website.

2. I agree with your point that the trend graph might be better suited for the documentation instead of the README. It would likely be a more fitting place to provide this kind of information. If you can guide me on how I can contribute to that part of the documentation, I am happy to implement it.

3. I started working on the website around 2023. As for me, I’m a passionate front-end developer who has been building websites since middle school. I currently work as a software engineer at a large NYSE-listed company and am also a member of the W3C. My love for front-end development has led me to create tools and resources that help developers, and npm-compare.com is one of my proudest projects.

4. Regarding GDPR compliance, I’ve done some research recently, and it turns out that if the data collection is anonymized (for instance, Google Analytics anonymizes IPs), and the data is being collected for necessary operational purposes (like ensuring the stability of the website), then an explicit opt-in mechanism may not be required under GDPR. I’m currently holding off on implementing a privacy confirmation dialog for now, as I believe it may negatively impact the user experience, but I’ll continue to monitor this to ensure compliance.

I’m open to any further suggestions. Thank you again for your consideration!

[cwtuan]

How about adding trend image here?

[ST-DDT]

I'm not sure about the location, but IMO the graph should show the downlads of the entire project duration without updates from our time side. Currently it is set to 3 years, so the first few months are already outside of this.
Sadly increasing the time range to higher values adds a lot of zero noise.

Would it be possible to pass a start date or alternatively filter leading zero values from an "alltime"/all graphs?

Do you have a GitHub repo/issue tracker as well?

[matthewmayer]

I think its a cool site when you are comparing libraries like this:

https://npm-compare.com/@faker-js/faker,casual,chance,faker/#timeRange=THREE_YEARS

As a standalone graph for one library, im not sure it tells me that much other than "there has been steady growth in downloads over the last three years".

Also, it's not clear what the y-axis represents. My assumption was daily downloads, but comparing with the official npm stats i think its actually weekly downloads? (We average about 6 million a week or 800K/day).

[ST-DDT]

As a standalone graph for one library, im not sure it tells me that much other than "there has been steady growth in downloads over the last three years".

I agree with this statement. I'm not opposed to adding it, but we should have someone from the team actually wanting this feature.

[matthewmayer]

Perhaps instead we could add a new section to awesome-faker called "statistics" and link to various third party sites which shows faker's download and ranking trends?

[cwtuan]

Changes done

1. I completed the "filter leading zero values" change, which helps to reduce unnecessary noise, particularly when dealing with larger time ranges. This ensures that the data is cleaner and more meaningful
2. I’ve also updated the title to "Package Weekly Downloads Trend" to make it clear and avoid any confusion.

I appreciate your valuable feedback!

Here are the results for @faker-js/faker trend for five years:

Before:

After:

Here are the results for @faker-js/faker vs faker vs chance vs casual trend for five years:

Before

After

[cwtuan]

I completely understand the concern with the large image in the README. To keep the README clean and still provide valuable info, I've update this PR which link the npm download badge directly to the npm-compare page for faker-js. This way, users can easily access more details without cluttering the README with a large image.

I also agree that it could be beneficial to have a dedicated statistics page on the documentation site, where the dynamic usage trends could be displayed more clearly. This would help users get a more visual view of the package's popularity, potentially boosting their confidence in choosing it.

[ST-DDT]

The changes look great. I had to manually refresh the stats page to reset the cache to actually see the change but it is better now.
I also think the new location associated with download stats work better together than just the large image.

What do the others think? Does clicking the download button match your expectation of clicking that button?

[matthewmayer]

Seems okay to me. Gives some more information than repeating the npm link on a second badge.

And appreciate the quick turnaround on making changes on your site !

[ST-DDT]

In case anybody is interested in collecting the data themselves:

https://github.com/npm/registry/blob/main/docs/download-counts.md

[cwtuan]

Thanks again for your advice, everyone.

[ST-DDT]

@cwtuan Thanks for your contribution.

If you want to add more registries/package proxies in the future you could add an option which registry to source the data from (maybe also adding them together).

Here is a link for metrics from jsdelivr:

• https://data.jsdelivr.com/v1/stats/packages/npm/@faker-js/faker?period=month
• https://www.jsdelivr.com/docs/data.jsdelivr.com#get-/v1/stats/packages/npm/-package-
• https://www.jsdelivr.com/docs/data.jsdelivr.com#get-/v1/stats/packages/npm/@-scope-/-package-

The API also return a npm package rank (typerank) and jsdelivr overall rank (rank). You could even build a rank graph by iterating over the weeks/days/months/years you are fetching:

https://data.jsdelivr.com/v1/stats/packages/npm/@faker-js/faker?period=2024-01