sindresorhus

notifier-for-github

Browser extension - Get notified about new GitHub notifications

by sindresorhus

JavaScript

JavaScript92.9%
HTML4.5%
CSS2.6%

Commit activity

Last 12 weeks · 0 commits

Full graph →

Community health

4 of 6 standards met

Community profile →
71
✓README✓License✓Contributing✓Code of Conduct○Issue Template○PR Template

Recent PRs & issues

Quiet · Last activity 1y ago
See all on GitHub →
zubin

Problem Notifications for draft PRs push up the badge count, even though drafts usually don't need attention yet. There's currently no way to leave them out. The only count filter is "Only show unread count for issues I'm participating in." Proposal Add an opt-in option (off by default): "Don't count draft pull requests." Why it can't be a simple query parameter The count comes from a single request: , then reading the last page number from the header. The notifications API doesn't include draft status. A notification only has and , so the only way to know if a PR is a draft is to fetch that PR and check its field. To keep costs down, the proposed change: Leaves the current single-request path untouched when the option is off, or when the count is 0. Only fetches PRs for unread notifications whose is . Caches each PR's draft status keyed by , and only re-fetches it when the notification's changes. After the first check, a typical poll costs little more than it does today. Fails open: if a PR can't be fetched, it is still counted. Proposed change , add the default: ~~~js filterNotifications: false, excludeDraftPullRequests: false ~~~ , under "Participating Count": ~~~html Don't count draft pull requests ~~~ , rename the existing to (unchanged body, not exported), then add: ~~~js // subject.url -> {updatedAt, draft} const draftCache = new Map(); async function isDraftPullRequest(notification) { const {subject, updated_at: updatedAt} = notification; if (subject.type !== 'PullRequest' !subject.url) { return false; } const cached = draftCache.get(subject.url); if (cached && cached.updatedAt === updatedAt) { return cached.draft; } try { // is absolute. On GitHub Enterprise its path starts with // , which already adds, so strip it. const endpoint = new URL(subject.url).pathname.replace(/^\/api\/v3/, ''); const {json: pullRequest} = await makeApiRequest(endpoint); const draft = pullRequest.draft === true; draftCache.set(subject.url, {updatedAt, draft}); return draft; } catch { // Fail open: count the notification if we can't tell return false; } } export async function getNotificationCount() { const result = await getRawNotificationCount(); const {excludeDraftPullRequests} = await optionsStorage.getAll(); if (!excludeDraftPullRequests result.count === 0) { return result; } // Respects , since it goes through const notifications = await getNotifications({}); // Drop cache entries for notifications that are no longer unread const currentUrls = new Set(notifications.map(notification => notification.subject.url)); for (const url of draftCache.keys()) { if (!currentUrls.has(url)) { draftCache.delete(url); } } const drafts = await Promise.all(notifications.map(notification => isDraftPullRequest(notification))); return { ...result, count: drafts.filter(isDraft => !isDraft).length }; } ~~~ needs no changes, since it only uses , and from the result. Trade-offs and open questions API usage. With the option on, each poll makes a few extra requests: pages of (100 per page), plus one per PR that isn't cached yet. The first poll with many unread PRs could make dozens of requests; after that, it's usually close to zero. This is why the option would be off by default. Cache lifetime. The cache lives in memory, so it resets when the MV3 service worker restarts. That's safe, just slightly more requests. It could be moved to if that matters. Draft marked ready for review. If a draft becomes ready without the notification's changing, the cached would be stale until the next update. A short TTL on cache entries would fix this if it turns out to happen in practice. Private repos. Fetching PR details needs the scope. Without it, those PRs fail open and are still counted. This could be mentioned next to the option. Scope.** This only changes the badge count. Desktop notifications and the notifications page opened by clicking the icon would still include drafts. Filtering desktop notifications could be a follow-up. I'm happy to open a PR if this approach sounds acceptable.

zubin · 3w ago
landeqiming666

Summary Restore recovery from offline state when the browser reports it is online again. Keep the connection helper from staying stuck in the offline state after a transient network loss. Add regression coverage for both the connection helper and background recovery path. Validation Fixes #132. IssueHunt Summary Referenced issues This pull request has been submitted to: #132: Notifier stays offline despite regaining connection

landeqiming666 · 3mo ago
mgrobaker

Summary This PR improves token documentation, adds fine-grained PAT format support for future compatibility, and fixes a bug preventing API requests in local development. Changes 1. Added fine-grained token format support in options.html Updated the token input pattern to accept format: While fine-grained PATs don't work yet (GitHub doesn't offer a Notifications permission), this future-proofs the extension for when GitHub adds that permission. 2. Fixed missing in manifest.json Added which is required for Manifest V3 extensions to make cross-origin fetch requests. Without this, locally-loaded extensions fail silently. 3. Improved token setup documentation Step-by-step instructions with direct links to GitHub token creation Clear scope table: (required) vs (optional for private repo deep links) Explains why fine-grained PATs don't work yet (GitHub's fine-grained PAT system has no Notifications permission) Security note for users concerned about scope 4. Other documentation improvements Consolidated GitHub Enterprise setup with step-by-step instructions Renamed "Permissions" → "Extension Permissions" to distinguish from GitHub token scopes Fixed "Notifications Permission" description (applies to all desktop notifications, not just public repos) Added "Testing Your Setup" section suggesting users watch a busy repo like microsoft/vscode 5. Security fixes** Ran to address vulnerabilities with non-breaking updates. Test plan [x] Verify classic PAT with scope works (badge count) [x] Verify fine-grained PAT is accepted by input but fails with 403 (expected until GitHub adds Notifications permission) [x] Verify locally-loaded extension makes API requests successfully 🤖 Generated with Claude Code

mgrobaker · 3mo ago
Structured data for AI agents

Repository: sindresorhus/notifier-for-github. Description: Browser extension - Get notified about new GitHub notifications Stars: 1989, Forks: 146. Primary language: JavaScript. Languages: JavaScript (92.9%), HTML (4.5%), CSS (2.6%). License: MIT. Topics: browser-extension, chrome-extension, firefox-addon, github, github-extension. Latest release: 25.6.25 (1y ago). Open PRs: 6, open issues: 21. Last activity: 1y ago. Community health: 71%. Top contributors: sindresorhus, notlmn, YurySolovyov, fregante, ArnaudLigny, PeterDaveHello, attilaolah, Hydrog3n, gcochard, TheBox193 and others.