rexios80 / pub_stats Goto Github PK

I'm thinking we have two options:

Store the package names in the Realtime Database during backend updates

Has the added benefit of only showing packages we have data for

Use the new optimized name completion endpoint

https://pub.dev/help/api#additional-apis
https://pub.dev/api/package-name-completion-data

Would need to PR pub_api_client to add this
Will not contain all packages we have data for (especially an issue if we use the suggestions to do things like adding to comparison)

What changes to track

Popularity

With high popularity, every percent is a huge achievement. Sometimes I tweet something like 'We are +1%!', so I want to learn it as soon as it happens. Also a drop in popularity may mean call for action.

Dependencies

If a new package starts to depend on mine, it is good news. If the package is popular, I may want to announce it. If a package has dropped the dependency on mine, they may have switched to a competitor, and I need to at least ask them for feedback.

How to get them

Alerts

Ideally I want to subscribe go get that on my email as soon as that is detected.

Feed

On a package page, I want to see a feed of such events in case I want to see the summary of what happened over say the last month instead of digging through separate emails.

Thank you for this beautiful website!

I wish there would be an option to show the graph of 2 packages side by side similar to

https://star-history.com/#flutter/flutter&facebook/react-native&Date

This would be awesome!

Steps to reproduce:

1. Open any package stats: https://pubstats.dev/#/packages/cupertino_icons
2. Edit the URL in the address bar to change the package name
3. Press Enter

Expected: Navigated to the new package.
Actual: The URL change is reverted, still viewing the old package.

The problem is from not using Navigator 2.0, and because the URL is parsed only once in DataController.create() in main().

Don't track transitive dependents

Right now we're using metrics.scorecard.panaReport.allDependencies to get package dependencies, but that includes transitive dependencies. Should we instead fetch a pubspec for each package and use pubspec.allDependencies which does not include transitive?

Pros:

• Less database storage
• Less container memory usage when processing package data

Cons:

• Requires an extra API call per package
• Do developers care about transitive dependents?

Don't track dependents for packages from Google-owned publishers

These packages have an exceptionally high number of dependents, and a significant amount are added every scan. There are so many dependents for these packages that I can't imagine anyone would care if they are tracked or not.

Pros:

• Less database storage

Cons:

• Google engineers might want this data?

Often we need to see how a package is performing against similar ones over time.

There are also official uses for that. It could be to get funding from the parent company, or to apply for talent immigration program, or anything else. Sure we can look at separate charts, but there are always people in authority who will act on a single chart from a proven source but will not trust a chart I compile myself, and will not bother reading explanation of multiple charts.

Also, this is just fun.

As a bonus, if this is implemented, FlutterGems may be interested in building charts for each category, and you can get traffic from them.