feat: enable TypeScript strict mode

[afonsojramos]

Summary

• Enables "strict": true in tsconfig.json
• Fixes ~292 strict mode errors across 94 files
• Makes generic onMainEvent/handleMainEvent IPC helpers to avoid type casting at every call site
• Adds proper null guards in notification handlers (discussion, issue, pullRequest)
• Changes timer hooks to accept number | null delay parameter
• Updates globalError type from GitifyError to GitifyError | undefined
• Converts null to undefined in optional Gitify type fields for consistency
• Adds err as Error casts in catch blocks
• All 931 tests pass

Test plan

• pnpm tsc --noEmit passes with zero errors
• All 133 test files pass (931 tests)
• Biome lint and format checks pass

[sonarqubecloud]

Quality Gate failed

Failed conditions
70.6% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[setchy]

Thanks @afonsojramos - spotted a few areas of feedback, will provide more detail when I'm in front of my computer next (currently on mobile)

[setchy]

I like this.

Should we be following this pattern in other places within src/main/* instead of mb.window?. ?

[afonsojramos]

Agreed! I’ll update events.ts, utils.ts, handlers/system.ts, and lifecycle/window.ts to use the early return guard pattern instead of optional chaining. It’s more explicit about the intent and consistent across src/main/*.

[setchy]

Should all these setters be wrapped with if (mb.window) {, or better yet, an early return if (!mb.window) { return }

[afonsojramos]

Good catch!! Since we already have the early return at the top for the on() calls, the mb.window?. inside the callbacks is redundant-looking but technically correct since the callbacks run later. I’ll consolidate with an early return inside each callback for consistency.

[setchy]

Could we instead reference the window default/initialized dimensions vs inlining these values again here?

[afonsojramos]

Good point. I’ll reference WindowConfig.width! and WindowConfig.height! (they’re typed as number | undefined by Electron’s BrowserWindowConstructorOptions but we always set them).

[setchy]

I believe raiseNativeNotification within src/preload/index.ts checks for null to determine whether to open the external link via a native notification. initializing to an empty string will break this logic

raiseNativeNotification: (title: string, body: string, url?: string) => {
    const notification = new Notification(title, { body: body, silent: true });
    notification.onclick = () => {
      if (url) {
        api.app.hide();
        api.openExternalLink(url, true);
      } else {
        api.app.show();
      }
    };

    return notification;
  }

[afonsojramos]

You’re right, the preload checks if (url) which would be falsy for null but truthy for an empty string ''. I’ll change it back to url: string | null = null to preserve the existing behavior.

[setchy]

What are your thoughts on using something like this for the catch/err patterns, instead of the casting

} catch (err: unknown) {
    if (err instanceof Error) {
       ......
    }
}

[afonsojramos]

That’s much safer pattern for sure! I’ll switch all the catch (err: unknown) blocks to use instanceof Error checks. For the logError calls that expect Error, we can also wrap with a fallback: logError(..., err instanceof Error ? err : new Error(String(err))).