If you encounter issues reading Greasy Fork's README, please visit the README on GitHub for a better experience.

🪄 Features

• No use of MutationObserver or setInterval, purely event-driven, making it more efficient than scripts of similar functionality
• No dangerous monkey patching, ensuring compatibility

⚙️ Configuation

• Personal Access Token: Your personal access token for GitHub API, starting with github_pat_ (used for increasing rate limit). For more information, see the Personal Access Token (PAT) section.
• Debug: Enable debug mode.
• Release Downloads: Show how many times a release asset has been downloaded.
• Release Uploader: Show who uploaded a release asset.
• Release Histogram: Show a histogram of download counts for each release asset.
  • Does not show up if there is only zero or one release asset.
  • Does not show up if none of the release assets have been downloaded.
• Tracking Prevention: Prevents some tracking by GitHub.

🖼️ Showcase

Example "Assets" section of a release on GitHub, with Release Downloads, Release Uploader and Release Histogram enabled:

🔑 Personal Access Token (PAT)

• Without a PAT, only $60$ requests per hour are allowed; with a PAT, $5000$ requests per hour are allowed, which suffices for most users.
• Find out how to create a fine-grained personal access token here.
• Simply select Public Repositories (read-only) under Repository access tab, which is the default setup. An example image is shown below for reference.
• Do note that this script won't be able to add additional information on private repositories.
• Remember to generate a new token when it expires.

Example setup for personal access token:

💡 Mechanism

For more detailed information, please refer to the source code. It is (hopefully) well-commented and contains other explanations and insights that may not be covered here.

Release * Features

• First, we need to listen for DOMContentLoaded and turbo:load events to know when DOM is ready or there has been a content change. In both cases, we need to re-check the page (setupListeners).
• Then, we should find all release-related include-fragment elements. By using devtools, we learn that they will be dynamically replaced with the actual content, so it's vital to investigate them.
• Search GitHub and we can find the repo for include-fragment with documentation. We can learn from the documentation that a include-fragment element will dispatch a include-fragment-replace event, just after the content has been fetched and parsed, and before it's inserted into the DOM. Better still, it comes with a handy detail.fragment property of type DocumentFragment, which is the parsed content.
• So, for each include-fragment element, we listen for the include-fragment-replace event and then process the detail.fragment to add our additional information (onFragmentReplace).
• In order to query additional information for a given release, we simply call the "Get a release by tag name" API. We can then extract the information we need and add it to the DocumentFragment.

Tracking Prevention Feature

By investigating source code (thanks for the source mapping) and setting breakpoints, we can find out that GitHub initializes tracking endpoints from certain <meta> tags. By removing these tags, we can prevent some tracking. More details can be found in the source code.

🤔 Known Issues

• The added information might not align well.