Conversation
WalkthroughThis update overhauls the project's configuration, build system, and Electron app structure. It introduces new configuration files for code formatting, linting, and editor settings, and replaces the previous Electron Forge/Webpack setup with electron-vite and electron-builder. The build and release workflows for GitHub Actions are restructured for clearer platform targeting and artifact management. Several Electron backend files, including configuration, packaging scripts, and utility modules, are removed or replaced with new implementations. API typings and IPC handler signatures are refined for improved type safety. Minor code style and JSX formatting changes are made throughout the renderer and onboarding components. Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant GitHub Actions
participant Electron Builder
participant Electron App
Developer->>GitHub Actions: Push tag or trigger build workflow
GitHub Actions->>GitHub Actions: Run build matrix (Ubuntu, macOS, Windows)
GitHub Actions->>Electron Builder: Build app for target OS
Electron Builder->>Electron App: Package app, apply config (electron-builder.json)
Electron Builder->>GitHub Actions: Upload build artifacts
Possibly related PRs
Suggested labels
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
iamEvanYT
force-pushed
the
evan/electron-vite-migration
branch
from
fb5724d to
1e2dc2e
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🔭 Outside diff range comments (1)
README.md (1)
81-84:⚠️ Potential issueBroken LICENSE reference
The README still links to./LICENSE, but the PR removed the license file. Restore the file or update this reference to the new license location to prevent a broken link.
🧹 Nitpick comments (36)
src/main/modules/typed-event-emitter.ts (1)
1-1: Prefer scoped ESLint disable over file-wide disables
The file-wide/* eslint-disable @typescript-eslint/no-explicit-any */suppresses all explicit-any warnings across the entire module. Consider narrowing the disabled scope to only the lines or declarations that truly requireany, or refactoring to useunknownor stronger generic types for better type safety.src/main/modules/queue.ts (1)
1-1: Scope ESLint disable to minimizeanyusage
Disabling@typescript-eslint/no-explicit-anyat the top of the file silences all explicit-any warnings. To maintain stricter typing, you could disable the rule inline only where necessary or replaceanywithunknownfor the queued task payloads and errors. Optionally, consider making theQueueclass itself generic to carry stronger type information.src/main/modules/output.ts (1)
1-1: Limit ESLint disable to specific cases
The top-level disable for@typescript-eslint/no-explicit-anysilences all explicit-any errors in this logging utility. Consider usingunknown[]for themessageparameter or scoping the rule disable to just thedebugPrintanddebugErrorsignatures to preserve type checks elsewhere.src/main/settings/main.ts (1)
71-71: Preferunknown[]or typed IPC arguments overany[]
Usingany[]for IPCsendMessagearguments bypasses type safety for inter-process communication. Consider switching tounknown[](and refining callers with type guards) or defining a union of allowed message payload types. Ifanyis unavoidable, you could disable the ESLint rule on just this line rather than globally..vscode/extensions.json (1)
1-3: Recommend adding Prettier extension
The ESLint extension is a great recommendation. Since the project also uses Prettier via.vscode/settings.jsonand.prettierignore, consider adding"esbenp.prettier-vscode"to the recommendations to streamline formatting in VS Code.src/main/onboarding/main.ts (1)
79-84: Refine usage ofanyin IPC method
Disablingno-explicit-anysuppresses type safety. Consider specifying a more precise type (e.g., a union of known payload shapes orunknown[]) and adding runtime validation instead of usingany.src/main/saving/open-external.ts (1)
45-47: Consider logging decode errors
Currently the catch block swallows all parsing errors. To aid debugging, you may want to log the exception (e.g., withconsole.warnor your logging utility) before returningnull.src/main/browser/tabs/tab-groups/glance.ts (1)
5-5: Typings improvement approved
Markingmodeas a constant assertion is correct for enforcing the literal type. Optionally, you can omit the explicit: "glance"annotation and rely on theas constassertion alone:- public mode: "glance" = "glance" as const; + public mode = "glance" as const;src/main/saving/datastore.ts (2)
10-12: Consider usingunknownor generics instead ofany
Suppressingno-explicit-anyhere is understandable for dynamic JSON data, but replacinganywithunknownor parameterizingDatawith a generic type would improve type safety.
186-195: Consider stronger typing forgetKeysresult
The inlineanydisables could be avoided by declaringgetKeysas returningRecord<K, unknown>or by introducing a generic mapping type. This will catch type errors when consumers use the result.src/main/browser/tabs/tab-groups/split.ts (2)
4-4: Refine themodeproperty declaration.The
modefield uses both a literal type annotation and anas constassertion, which is redundant. You can simplify this to:public readonly mode = "split" as const;or drop the
as constif you keep the type annotation:public readonly mode: "split" = "split";Either option reduces redundancy and clarifies intent.
6-6: Implement or remove the placeholder.The
TODOindicates that the split tab group layout is not yet implemented. Consider providing a basic stub implementation or converting the class toabstractuntil the layout logic is available. Alternatively, track this work in an issue and remove theTODOfrom source..gitignore (1)
1-6: Review the minimal ignore patterns.The
.gitignorehas been drastically trimmed to only core artifacts. Verify that you’re not missing patterns for:
- IDE/editor settings (e.g.
.vscode/,.idea/)- Environment files (e.g.
.env)- Build artifacts from electron-builder (e.g.
release/*,app-*.*)- Coverage reports (
coverage/)- OS-specific files beyond
.DS_Store(e.g.Thumbs.db)Adding these back as needed will prevent accidental commits of sensitive or bulky files.
src/main/sessions/profiles.ts (1)
17-17: Rethink suppressing the unused schema.Rather than disabling the linter for
ProfileDataSchema, consider:
- Using
ProfileDataSchemato parse/validate incoming data ingetProfileor CRUD operations.- Prefixing the variable with
_(e.g._ProfileDataSchema) if it’s purely for typing.If you truly won’t use the schema at runtime, an
eslint-disableis acceptable, but adding basic validation could improve data integrity.src/main/ipc/listeners-manager.ts (1)
4-4: ESLint disable for explicit any is acceptable but consider scoping.
Disabling@typescript-eslint/no-explicit-anyat the file level aligns with the broader migration, but you might restrict the disable to only the specific functions or lines that genuinely requireany, or replace withunknownand add type guards to improve type safety.src/renderer/src/components/browser-ui/sidebar/header/address-bar/pinned-browser-actions.tsx (1)
91-92: Consider usingxlinkHrefinstead of disabling lint
Rather than suppressingreact/no-unknown-property, leverage the React-supportedxlinkHrefprop for the SVG<image>element. This removes the need for ESLint suppression and aligns with SVG attribute conventions:- {/* eslint-disable-next-line react/no-unknown-property */} - <image href={iconUrl} className="size-4 object-contain shrink-0" onError={() => setIsError(true)} /> + <image xlinkHref={iconUrl} className="size-4 object-contain shrink-0" onError={() => setIsError(true)} />src/renderer/src/components/browser-ui/browser-action.tsx (1)
59-60: UsexlinkHrefto avoid lint suppression
Instead of disabling the lint rule, switch to thexlinkHrefprop on the SVG<image>element to satisfy React’s supported attributes:- {/* eslint-disable-next-line react/no-unknown-property */} - <image href={iconUrl} className="size-4 object-contain shrink-0" onError={() => setIsError(true)} /> + <image xlinkHref={iconUrl} className="size-4 object-contain shrink-0" onError={() => setIsError(true)} />src/renderer/src/components/onboarding/stages/initial-space/create.tsx (1)
109-109: Style change: Direct string replaced with JSX expression.The change from a direct string to a JSX expression with curly braces doesn't affect functionality but seems to be part of a consistent styling approach across the codebase.
While both approaches are valid in React, using plain text (
<p>Text</p>) is generally simpler than the JSX expression syntax (<p>{"Text"}</p>) when no dynamic content or expressions are needed. This change might be related to a linting rule or preparation for internationalization.src/main/modules/extensions/permission-warnings.ts (1)
597-624: Code still contains an unused variable.The
hasSpecificHostReadWritevariable on line 606 is assigned a value but never read or used elsewhere in the function.Consider removing the unused
hasSpecificHostReadWritevariable to improve code cleanliness. It's assigned in theforEachloop but its value is never used afterward.- let hasSpecificHostReadWrite = false; availablePermissions.forEach((perm) => { if (isSpecificHostPermission(perm) && perm !== "<all_urls>") { - hasSpecificHostReadWrite = true; // Mark the specific host perm for removal later if matched by a generic rule } });src/main/browser/browser.ts (2)
68-70: Consider logging errors in catch blocksThe error parameter was removed from the catch block, which is fine if the error is not being used. However, for better debugging, consider logging the error before returning false.
- } catch { + } catch (error) { + console.error("Failed to load profile:", profileId, error); return false;
181-188: Consider using a more specific type instead of any[]While the ESLint disable directive is a common practice for variadic arguments, consider using a more specific type union for the
argsparameter if possible.- // eslint-disable-next-line @typescript-eslint/no-explicit-any - public sendMessageToCoreWebContents(channel: string, ...args: any[]) { + public sendMessageToCoreWebContents(channel: string, ...args: (string | number | boolean | object | null | undefined)[]) {If the exact types are unknown or too varied, the current approach with the ESLint disable comment is acceptable.
src/main/browser/close-preventer.ts (2)
35-40: Consider a more event-driven approach for WebContents tracking.The current implementation calls
scan()every 100ms, which could be inefficient. Consider using Electron's events to detect new WebContents.-if (enabled) { - scan(); - setInterval(() => { - scan(); - }, 100); +if (enabled) { + // Initial scan for existing WebContents + scan(); + + // Listen for new WebContents + app.on('web-contents-created', (_event, contents) => { + newWebContents(contents); + }); }
4-6: Add appropriate TypeScript types for input event parameters.The
inputparameter in the event handler lacks explicit typing, which could lead to potential type errors.-import { type WebContents, webContents } from "electron"; +import { type WebContents, webContents, Input } from "electron"; import { menuCloseTab } from "./utility/menu/items/view"; import { browser } from "@/index";And in the event handler:
- webContents.on("before-input-event", (event, input) => { + webContents.on("before-input-event", (event, input: Input) => {eslint.config.mjs (1)
30-33: Consider more targeted rule disabling.Completely disabling
@typescript-eslint/explicit-function-return-typemight reduce type safety in the codebase. Consider a more targeted approach.{ rules: { - "@typescript-eslint/explicit-function-return-type": "off", + "@typescript-eslint/explicit-function-return-type": ["warn", { + "allowExpressions": true, + "allowTypedFunctionExpressions": true, + "allowHigherOrderFunctions": true, + "allowDirectConstAssertionInArrowFunctions": true, + "allowConciseArrowFunctionExpressionsStartingWithVoid": true + }], "react-refresh/only-export-components": "off" } }This configuration maintains type safety while reducing noise for React components and other common patterns.
.vscode/launch.json (1)
8-12: Use updated VSCode variables for workspace paths
The${workspaceRoot}variable is deprecated in favor of${workspaceFolder}. Updating this will ensure compatibility with current and future VSCode versions.
Apply this diff:- "cwd": "${workspaceRoot}", - "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron-vite", - "windows": { - "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron-vite.cmd" - }, + "cwd": "${workspaceFolder}", + "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron-vite", + "windows": { + "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron-vite.cmd" + },electron.vite.config.ts (1)
6-8: Use absolute paths based on__dirnamefor aliases
Callingresolve("src/main")relies on the current working directory. For more robust aliasing across environments, consider:const mainAliases: Record<string, string> = { "@": resolve(__dirname, "../../src/main") };src/main/modules/paths.ts (1)
5-7: Clarify build output directory constants
OUT_DIR = path.join(__dirname, "..")andROOT_DIR = path.join(OUT_DIR, "..")work but can be confusing. Consider renaming toMAIN_OUT_DIRandDIST_DIRor adding a comment explaining the folder structure post-build for maintainability..github/workflows/build.yml (3)
22-26: Remove unused Yarn installation
This workflow installs Yarn but never uses it; all dependency steps are handled by Bun. Removing the Yarn setup step will speed up execution and reduce surface area:- - name: Install Node.js, NPM and Yarn - uses: actions/setup-node@v4 - with: - node-version: 22 + - name: Install Node.js + uses: actions/setup-node@v4 + with: + node-version: 22
42-44: Cache Bun dependencies to accelerate builds
Reinstalling dependencies on every run can be slow. Consider adding a caching step:- name: Cache Bun dependencies uses: actions/cache@v3 with: path: | ~/.bun key: ${{ runner.os }}-bun-${{ hashFiles('bun.lockb') }}
45-55: DRY up platform-specific build commands
The three separate steps can be replaced by a single step using a matrix variable:- - name: Build for Linux - if: matrix.os == 'ubuntu-latest' - run: bun run build:linux - - name: Build for macOS - if: matrix.os == 'macos-latest' - run: bun run build:mac - - name: Build for Windows - if: matrix.os == 'windows-latest' - run: bun run build:win + - name: Run build command + run: bun run build:${{ matrix.os == 'ubuntu-latest' && 'linux' || matrix.os == 'macos-latest' && 'mac' || 'win' }}CONTRIBUTING.md (1)
65-72: Include Bun in the technology stack for consistency
The prerequisites require Bun, but it’s missing from the “Technology Stack” section. Adding it will help new contributors understand the runtime dependencies. Apply this diff:- - **Build Tools**: Electron Builder, electron-vite, Vite, TypeScript + - **Build Tools**: Electron Builder, electron-vite, Vite, TypeScript, Bunelectron-builder.json (1)
40-59: Consider updating Linux category for better discoverabilityFor a browser application, the Linux category "Utility" may not be optimal for discoverability in application menus and stores.
"linux": { "target": ["AppImage", "deb", "flatpak"], - "category": "Utility" + "category": "Network" },The "Network" or "WebBrowser" category would be more appropriate for a browser application according to the freedesktop.org desktop entry specification.
src/main/browser/utility/hot-reload.ts (1)
58-59: Remove or fix ts-ignore commentThere's a ts-ignore comment for URL.parse that could be addressed with proper typing.
- // @ts-ignore: URL.parse should work, but tsc thinks it doesn't - const reqURL = URL.parse(request?.url); + // Use URL constructor instead of deprecated URL.parse + const reqURL = request?.url ? new URL(request.url) : null;The URL.parse method is deprecated in favor of the URL constructor, which provides better typing support.
package.json (1)
22-26: Inconsistent build commandsThere's an inconsistency in how the build commands are structured.
- "build:win": "npm run build && electron-builder --win", - "build:mac": "electron-vite build && electron-builder --mac", - "build:linux": "electron-vite build && electron-builder --linux" + "build:win": "npm run build && electron-builder --win", + "build:mac": "npm run build && electron-builder --mac", + "build:linux": "npm run build && electron-builder --linux"The Mac and Linux build commands should use
npm run buildlike the Windows command does to ensure type checking is performed before building.src/main/browser/tabs/tab-context-menu.ts (1)
184-185: Fix the ts-expect-error with proper typingThere's a ts-expect-error comment that should be addressed with proper typing rather than being suppressed.
- // @ts-expect-error: ts error, but still works - const items: Electron.MenuItemConstructorOptions[] = extensions.getContextMenuItems(tab.webContents, parameters); + // Define proper interface for extensions object + interface ExtensionManager { + getContextMenuItems(webContents: Electron.WebContents, parameters: Electron.ContextMenuParams): Electron.MenuItemConstructorOptions[]; + } + + const items: Electron.MenuItemConstructorOptions[] = (extensions as ExtensionManager).getContextMenuItems(tab.webContents, parameters);This approach maintains type safety while documenting the expected interface of the extensions object, making the code more maintainable.
src/preload/index.ts (1)
136-138: Consider addressing the type inconsistencies instead of suppressing themThe
@ts-expect-errorcomment suppresses TypeScript errors but doesn't fix the underlying issue. While this may be necessary during migration, it would be better to refactor the code to properly handle the type inconsistencies.Consider refactoring the wrapper function to use proper generic typing that preserves the function signatures. This might involve a more complex type definition but would eliminate the need for type assertions and error suppression.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (78)
assets/public/icons/3d.pngis excluded by!**/*.pngassets/public/icons/darkness.pngis excluded by!**/*.pngassets/public/icons/default.pngis excluded by!**/*.pngassets/public/icons/glowy.pngis excluded by!**/*.pngassets/public/icons/minimal_flat.pngis excluded by!**/*.pngassets/public/icons/nature.pngis excluded by!**/*.pngassets/public/icons/retro.pngis excluded by!**/*.pngassets/public/icons/summer.pngis excluded by!**/*.pngbuild/icon.icois excluded by!**/*.icobuild/icon.pngis excluded by!**/*.pngbun.lockis excluded by!**/*.lockdocs/assets/screenshots/beta-browser-1.pngis excluded by!**/*.pngdocs/assets/screenshots/beta-command-1.pngis excluded by!**/*.pngdocs/assets/screenshots/beta-newtab-1.pngis excluded by!**/*.pngdocs/assets/screenshots/beta-onboarding-1.pngis excluded by!**/*.pngdocs/assets/screenshots/beta-settings-1.pngis excluded by!**/*.pngsrc/renderer/public/assets/favicon.icois excluded by!**/*.icosrc/renderer/public/assets/icon.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/favicon.icois excluded by!**/*.icosrc/renderer/public/chrome-dino-game/icons/icon-114.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/icons/icon-128.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/icons/icon-16.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/icons/icon-256.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/icons/icon-32.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_100_percent/offline/100-disabled.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_100_percent/offline/100-error-offline.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_100_percent/offline/100-offline-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_100_percent/offline/100-olympic-firemedal-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_100_percent/offline/100-olympics-equestrian-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_100_percent/offline/100-olympics-gymnastics-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_100_percent/offline/100-olympics-hurdling-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_100_percent/offline/100-olympics-surfing-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_100_percent/offline/100-olympics-swimming-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_200_percent/offline/200-disabled.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_200_percent/offline/200-error-offline.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_200_percent/offline/200-offline-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_200_percent/offline/200-olympic-firemedal-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_200_percent/offline/200-olympics-equestrian-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_200_percent/offline/200-olympics-gymnastics-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_200_percent/offline/200-olympics-hurdling-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_200_percent/offline/200-olympics-surfing-sprite.pngis excluded by!**/*.pngsrc/renderer/public/chrome-dino-game/images/default_200_percent/offline/200-olympics-swimming-sprite.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/android-icon-144x144.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/android-icon-192x192.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/android-icon-36x36.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/android-icon-48x48.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/android-icon-72x72.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/android-icon-96x96.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-114x114.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-120x120.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-144x144.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-152x152.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-180x180.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-57x57.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-60x60.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-72x72.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-76x76.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon-precomposed.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/apple-icon.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/favicon.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/favicon.svgis excluded by!**/*.svgsrc/renderer/public/edge-surf-game-v1/resources/icons/ms-icon-144x144.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/ms-icon-150x150.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/ms-icon-310x310.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/icons/ms-icon-70x70.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/ski/bg.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/ski/objects.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/ski/player.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/surf/bg.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/surf/objects.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v1/resources/surf/player.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v2/favicon.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v2/favicon.svgis excluded by!**/*.svgsrc/renderer/public/edge-surf-game-v2/icons/icon-114.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v2/icons/icon-128.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v2/icons/icon-16.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v2/icons/icon-256.pngis excluded by!**/*.pngsrc/renderer/public/edge-surf-game-v2/icons/icon-32.pngis excluded by!**/*.png
📒 Files selected for processing (94)
.editorconfig(1 hunks).github/workflows/build-and-release.yml(3 hunks).github/workflows/build.yml(1 hunks).gitignore(1 hunks).prettierignore(1 hunks).vscode/extensions.json(1 hunks).vscode/launch.json(1 hunks).vscode/settings.json(1 hunks)CONTRIBUTING.md(3 hunks)LICENSE(0 hunks)README.md(3 hunks)electron-builder.json(1 hunks)electron.vite.config.ts(1 hunks)electron/.gitignore(0 hunks)electron/browser/close-preventer.ts(0 hunks)electron/browser/utility/views.ts(0 hunks)electron/build/set-locales.ts(0 hunks)electron/forge.config.ts(0 hunks)electron/ipc/browser/browser.ts(0 hunks)electron/modules/paths.ts(0 hunks)electron/package.json(0 hunks)electron/tsconfig.json(0 hunks)electron/webpack.main.config.js(0 hunks)electron/webpack.renderer.config.js(0 hunks)eslint.config.mjs(1 hunks)extensions/README.md(0 hunks)package.json(1 hunks)scripts/sync-version.ts(0 hunks)src/main/browser/browser.ts(2 hunks)src/main/browser/close-preventer.ts(1 hunks)src/main/browser/components/omnibox.ts(1 hunks)src/main/browser/components/portal-component-windows.ts(3 hunks)src/main/browser/profile-manager.ts(3 hunks)src/main/browser/sessions.ts(1 hunks)src/main/browser/tabs/tab-bounds.ts(0 hunks)src/main/browser/tabs/tab-context-menu.ts(9 hunks)src/main/browser/tabs/tab-groups/glance.ts(1 hunks)src/main/browser/tabs/tab-groups/split.ts(1 hunks)src/main/browser/tabs/tab-manager.ts(0 hunks)src/main/browser/tabs/tab.ts(4 hunks)src/main/browser/utility/hot-reload.ts(3 hunks)src/main/browser/utility/menu.ts(1 hunks)src/main/browser/utility/menu/helpers.ts(0 hunks)src/main/browser/utility/menu/items/spaces.ts(3 hunks)src/main/browser/utility/menu/items/view.ts(1 hunks)src/main/browser/utility/protocols.ts(5 hunks)src/main/browser/window-manager.ts(2 hunks)src/main/browser/window.ts(1 hunks)src/main/index.ts(5 hunks)src/main/ipc/app/extensions.ts(1 hunks)src/main/ipc/browser/browser.ts(1 hunks)src/main/ipc/browser/navigation.ts(2 hunks)src/main/ipc/browser/page.ts(1 hunks)src/main/ipc/listeners-manager.ts(1 hunks)src/main/ipc/session/profiles.ts(1 hunks)src/main/ipc/session/spaces.ts(3 hunks)src/main/ipc/window/settings.ts(1 hunks)src/main/modules/extensions/locales.ts(1 hunks)src/main/modules/extensions/main.ts(1 hunks)src/main/modules/extensions/management.ts(1 hunks)src/main/modules/extensions/permission-warnings.ts(1 hunks)src/main/modules/favicons.ts(2 hunks)src/main/modules/icons.ts(1 hunks)src/main/modules/output.ts(1 hunks)src/main/modules/paths.ts(1 hunks)src/main/modules/queue.ts(1 hunks)src/main/modules/typed-event-emitter.ts(1 hunks)src/main/onboarding/main.ts(1 hunks)src/main/saving/datastore.ts(2 hunks)src/main/saving/open-external.ts(1 hunks)src/main/saving/tabs.ts(1 hunks)src/main/sessions/profiles.ts(1 hunks)src/main/sessions/spaces.ts(4 hunks)src/main/settings/main.ts(1 hunks)src/preload/index.ts(17 hunks)src/renderer/src/components/browser-ui/browser-action.tsx(1 hunks)src/renderer/src/components/browser-ui/sidebar/header/address-bar/pinned-browser-actions.tsx(1 hunks)src/renderer/src/components/omnibox/main.tsx(1 hunks)src/renderer/src/components/onboarding/screen.tsx(3 hunks)src/renderer/src/components/onboarding/stages/finish.tsx(1 hunks)src/renderer/src/components/onboarding/stages/icon.tsx(1 hunks)src/renderer/src/components/onboarding/stages/initial-space/create.tsx(3 hunks)src/renderer/src/components/onboarding/stages/initial-space/icon.tsx(1 hunks)src/renderer/src/components/onboarding/stages/new-tab.tsx(1 hunks)src/renderer/src/components/onboarding/stages/sidebar-collapse-mode.tsx(1 hunks)src/renderer/src/components/settings/sections/external-apps/section.tsx(1 hunks)src/renderer/src/components/settings/sections/general/basic-settings-cards.tsx(1 hunks)src/renderer/src/components/settings/sections/general/reset-onboarding-card.tsx(1 hunks)src/renderer/src/components/settings/sections/general/section.tsx(1 hunks)src/renderer/src/components/settings/sections/profiles/section.tsx(3 hunks)src/renderer/src/components/settings/sections/spaces/editor-tabs.tsx(2 hunks)src/renderer/src/components/settings/sections/spaces/space-dialogs.tsx(1 hunks)src/renderer/src/components/ui/badge.tsx(1 hunks)src/renderer/src/components/ui/dropdown-menu.tsx(10 hunks)
💤 Files with no reviewable changes (17)
- src/main/browser/utility/menu/helpers.ts
- src/main/browser/tabs/tab-manager.ts
- src/main/browser/tabs/tab-bounds.ts
- extensions/README.md
- electron/.gitignore
- scripts/sync-version.ts
- electron/webpack.renderer.config.js
- electron/browser/close-preventer.ts
- electron/browser/utility/views.ts
- electron/package.json
- electron/ipc/browser/browser.ts
- electron/webpack.main.config.js
- electron/build/set-locales.ts
- electron/modules/paths.ts
- electron/tsconfig.json
- LICENSE
- electron/forge.config.ts
🧰 Additional context used
🧬 Code Graph Analysis (10)
src/main/browser/utility/menu.ts (1)
src/main/browser/utility/menu/items/spaces.ts (1)
createSpacesMenu(155-209)
src/main/ipc/window/settings.ts (1)
src/main/saving/settings.ts (2)
getSettingValueById(38-40)setSettingValueById(58-64)
src/main/ipc/browser/navigation.ts (1)
src/main/index.ts (1)
browser(10-10)
src/main/index.ts (1)
src/main/browser/window.ts (1)
TabbedBrowserWindow(28-252)
src/main/browser/window-manager.ts (1)
src/main/browser/window.ts (1)
TabbedBrowserWindow(28-252)
src/main/ipc/browser/browser.ts (1)
src/main/index.ts (1)
browser(10-10)
src/main/ipc/session/spaces.ts (2)
src/main/sessions/spaces.ts (6)
getSpaces(232-256)getSpacesFromProfile(172-230)createSpace(84-129)deleteSpace(158-170)SpaceData(29-29)getLastUsedSpace(288-304)src/main/browser/utility/utils.ts (1)
generateID(24-26)
src/main/browser/close-preventer.ts (2)
src/main/index.ts (1)
browser(10-10)src/main/browser/utility/menu/items/view.ts (1)
menuCloseTab(10-34)
src/main/browser/utility/protocols.ts (1)
src/main/browser/utility/hot-reload.ts (1)
isDevelopmentServerRunning(21-27)
src/preload/index.ts (18)
src/shared/flow/interfaces/browser/browser.ts (1)
FlowBrowserAPI(2-19)src/shared/flow/interfaces/browser/tabs.ts (1)
FlowTabsAPI(5-42)src/shared/types/tabs.ts (1)
WindowTabsData(49-54)src/shared/flow/interfaces/browser/page.ts (1)
FlowPageAPI(4-12)src/shared/flow/interfaces/browser/navigation.ts (1)
FlowNavigationAPI(16-53)src/shared/flow/interfaces/browser/interface.ts (1)
FlowInterfaceAPI(4-38)src/shared/flow/interfaces/sessions/profiles.ts (1)
FlowProfilesAPI(7-32)src/shared/flow/interfaces/sessions/spaces.ts (1)
FlowSpacesAPI(13-68)src/shared/flow/interfaces/app/app.ts (1)
FlowAppAPI(2-25)src/shared/flow/interfaces/settings/icons.ts (1)
FlowIconsAPI(9-29)src/shared/flow/interfaces/browser/newTab.ts (1)
FlowNewTabAPI(4-9)src/shared/flow/interfaces/settings/openExternal.ts (1)
FlowOpenExternalAPI(7-17)src/shared/flow/interfaces/settings/onboarding.ts (1)
FlowOnboardingAPI(2-12)src/shared/flow/interfaces/browser/omnibox.ts (1)
FlowOmniboxAPI(6-16)src/shared/flow/interfaces/settings/settings.ts (1)
FlowSettingsAPI(5-27)src/shared/flow/interfaces/app/windows.ts (1)
FlowWindowsAPI(2-12)src/shared/flow/interfaces/app/extensions.ts (1)
FlowExtensionsAPI(5-30)src/shared/types/extensions.ts (1)
SharedExtensionData(5-19)
🪛 LanguageTool
README.md
[style] ~41-~41: Using many exclamation marks might seem excessive (in this case: 5 exclamation marks for a text that’s 3188 characters long)
Context: ...sets/screenshots/beta-onboarding-1.png) 
🔇 Additional comments (107)
src/main/browser/components/omnibox.ts (1)
1-1: Clean up unused imports
Great catch removing the unusedipcMainimport from Electron. This keeps the codebase lean and avoids unnecessary bundle overhead..editorconfig (1)
1-9: Approve EditorConfig standardization
The new.editorconfigestablishes consistent indentation, encoding, and line endings across all files, aligning with project formatting guidelines.README.md (3)
6-6: Confirm updated logo path
The logo path was changed to./build/icon.png. Verify that the build output from electron-vite/Electron Builder places the icon at this location so the image renders correctly in the README.
41-45: Validate screenshot asset paths
Screenshot sources were moved to./docs/assets/screenshots/. Ensure these files exist in the repository at the specified paths or update the paths accordingly.🧰 Tools
🪛 LanguageTool
[style] ~41-~41: Using many exclamation marks might seem excessive (in this case: 5 exclamation marks for a text that’s 3188 characters long)
Context: ...sets/screenshots/beta-onboarding-1.png)(EN_EXCESSIVE_EXCLAMATION)
58-58: Verify feature implementation
You’ve promoted Persist Tabs to the main Features list. Confirm that this functionality is implemented and covered by tests before highlighting it as available.src/renderer/src/components/ui/badge.tsx (2)
1-23: Skip formatting-only changes
All modifications in this range are stylistic (semicolons, line breaks, object/JSX formatting). No behavioral or API changes were introduced.
30-36: Skip formatting-only changes
These lines consolidate the JSX return and adjust spacing; behavior is unchanged.src/main/browser/components/portal-component-windows.ts (3)
61-69: Approve renaming unusedeventparameter
Changingeventto_eventclearly indicates the parameter is unused without affecting the IPC handler logic.
71-78: Approve renaming unusedeventparameter
Updating to_eventimproves code clarity and follows the convention for unused parameters.
80-87: Approve renaming unusedeventparameter
Consistent underscore prefix for unused IPC event parameters enhances readability and intention.src/renderer/src/components/ui/dropdown-menu.tsx (2)
1-5: Stylistic formatting changes applied.The updates here are purely formatting (added semicolons, adjusted line breaks, and standardized JSX returns) to align with the project's ESLint/Prettier configuration. There are no functional changes.
Also applies to: 36-36, 39-39, 63-63, 89-89, 92-93, 117-117, 125-131, 134-134, 145-145, 147-147, 152-152, 155-155, 158-158, 183-183, 198-198, 216-217
49-50: Good use of explicit prop typing.Defining
inset?: booleanandvariant?: "default" | "destructive"onDropdownMenuItemimproves clarity and type safety. This makes the component’s API more self-documenting.src/main/browser/utility/menu/items/view.ts (1)
73-73: Formatting-only change.The added semicolon after
menuCloseTab(browser);is a non-functional formatting update that aligns with the new style rules.src/main/ipc/app/extensions.ts (1)
2-2: Removed unusedsendMessageToListenersWithWebContentsimport.
Great cleanup—removing the unused import declutters the module and avoids dead code.src/main/modules/icons.ts (1)
1-1: Removed unusedipcMainimport.
Excellent removal of the leftoveripcMainimport from Electron, streamlining dependencies to what's actually used.src/renderer/src/components/onboarding/stages/new-tab.tsx (1)
28-28: Consistent JSX string expression usage.
Switching to an explicit JSX string expression preserves functionality while standardizing the way literals are embedded in JSX across the codebase.src/renderer/src/components/onboarding/stages/sidebar-collapse-mode.tsx (1)
28-28: Aligned paragraph content syntax.
Updating the paragraph to use a JSX expression keeps behavior unchanged and matches the style pattern adopted in other onboarding components.src/renderer/src/components/settings/sections/general/reset-onboarding-card.tsx (1)
47-47: Standardized JSX string syntax.This change is purely stylistic, replacing a multi-line text block with an equivalent template literal. This fits with the overall standardization of JSX string syntax in the codebase.
src/renderer/src/components/settings/sections/general/section.tsx (1)
9-9: Standardized JSX string syntax.This change wraps the plain string in a JSX expression with curly braces, maintaining consistent string handling throughout the codebase without affecting the rendered output.
src/main/browser/utility/menu.ts (1)
24-24: Signature update for createSpacesMenu function.The removal of the
browserparameter aligns with the refactoredcreateSpacesMenufunction that no longer depends on the Browser instance. This update correctly matches the updated function signature as part of the larger refactoring effort.src/renderer/src/components/onboarding/stages/finish.tsx (1)
41-41: Standardized JSX string syntax.This change wraps the heading text in JSX expression braces, consistent with similar changes throughout the codebase. This standardization improves code consistency without affecting the rendered output.
src/main/saving/tabs.ts (1)
12-12:Details
❓ Verification inconclusive
Temporary disabling of tab groups persistence
The TabGroupsDataStore initialization has been commented out as part of the migration to electron-vite. This aligns with the TODO comment on line 14 about persisting tab groups.
Since this affects persistence functionality, can you confirm this was intentional and whether there's a plan to re-implement tab groups persistence after the migration?
🏁 Script executed:
#!/bin/bash # Check if tabgroups are referenced elsewhere that might be affected by this change echo "Checking for tabgroups usage in the codebase:" rg "tabgroups" --type tsLength of output: 206
Confirm tab groups persistence removal and re-implementation plan
We searched the codebase for “tabgroups” and found only the commented-out initialization in
src/main/saving/tabs.ts(line 12). With no other references, tab groups persistence is effectively disabled. Please confirm that this was intentional and share the plan or timeline for re-implementing tab groups persistence post-migration to electron-vite.
- File:
src/main/saving/tabs.ts- Line: 12
- Snippet:
// const TabGroupsDataStore = getDatastore("tabgroups");src/renderer/src/components/onboarding/stages/icon.tsx (1)
120-120: JSX syntax standardizationConverting plain text to a JavaScript string expression in JSX maintains consistent syntax across the codebase.
This change is part of a broader effort to standardize JSX text embedding without affecting functionality.
src/main/browser/window.ts (1)
201-202: ESLint rule suppression for API with variable argumentsAdding an ESLint disable directive for the no-explicit-any rule is appropriate here given the nature of the IPC messaging function that needs to handle arbitrary argument types.
This pragmatic approach allows the codebase to comply with stricter linting rules while acknowledging that some APIs inherently need flexible type handling.
In a future refactoring, consider using a more specific union type or generic type parameter if the message patterns become more standardized.
src/main/browser/sessions.ts (1)
44-45: Explicit fall-through comment added as intended
The added/* falls through */clarifies the intentional control flow fromcase 2intocase 1, satisfying linter requirements and improving code readability without altering behavior..vscode/settings.json (1)
1-11: Prettier configured as the default formatter
This VSCode workspace setting ensures TypeScript, JavaScript, and JSON files are consistently formatted with Prettier, aligning with the project’s formatting strategy and the added.editorconfigand ESLint setup.src/main/ipc/window/settings.ts (3)
15-17: Rename unusedeventparameter to_event
Renaming to_eventcorrectly conveys that the IPC event object is unused in thesettings:get-settinghandler, satisfying lint rules and improving code clarity.
19-21: Mark the unused IPCeventparameter explicitly
Changingeventto_eventin thesettings:set-settinghandler prevents unused variable warnings and documents that the event object isn’t used in the callback.
23-28: Omit unused parameters insettings:get-basic-settingshandler
Removing all parameters from this IPC handler is consistent with otheripcMain.handlecallbacks and clearly indicates that no arguments are needed.src/renderer/src/components/settings/sections/external-apps/section.tsx (2)
161-163: Consistent JSX string expressions
Conversion of the<p>child to an explicit string expression aligns with the project's JSX consistency guidelines and has no impact on runtime behavior.
170-171: Approve explicit string inCardDescription
Wrapping the description text in a JSX string literal standardizes formatting without altering functionality—👍src/renderer/src/components/onboarding/stages/initial-space/icon.tsx (1)
120-121: Standardize JSX text child
Switching the plain text to a JSX string literal maintains identical UI behavior while enforcing consistency across components.src/main/modules/extensions/management.ts (1)
118-119: Tighten manifest icon typing
Assertingmanifest.iconstoRecord<string, string>improves type safety when accessing by key. This is a welcome refinement.src/renderer/src/components/settings/sections/spaces/editor-tabs.tsx (2)
35-35: ConvertCardDescriptionto JSX string literal
This change enforces a consistent pattern for static text in JSX without affecting behavior.
134-134: Enforce JSX literal syntax
Updating the secondCardDescriptionto an explicit string literal matches the project's formatting conventions.src/main/ipc/browser/page.ts (1)
18-18: Simplify early return
Removing the explicitnullreturn in favor of a barereturn(i.e.,undefined) is consistent with void-returning IPC handlers and does not change behavior.src/main/modules/favicons.ts (2)
169-169: Good simplification of error handlingThe removal of the unused error parameter in the catch block improves code cleanliness without affecting functionality. The error information isn't needed since the retry logic only depends on the retry count.
279-279: Improved type safety with Buffer array declarationChanging from a mutable variable to an explicitly typed constant array is a good practice. Since the array reference never changes (only its contents), using
constwith proper typing makes the code more predictable and type-safe.src/main/ipc/session/profiles.ts (3)
11-11: Properly marked unused parameterRenaming the unused
eventparameter to_eventfollows TypeScript conventions for indicating intentionally unused parameters, improving code clarity.
16-16: Properly marked unused parameterRenaming the unused
eventparameter to_eventfollows TypeScript conventions for indicating intentionally unused parameters, improving code clarity.
21-21: Properly marked unused parameterRenaming the unused
eventparameter to_eventfollows TypeScript conventions for indicating intentionally unused parameters, improving code clarity.src/renderer/src/components/settings/sections/profiles/section.tsx (3)
68-68: Consistent string handling in JSXConverting the plain text to a JSX expression improves consistency with other string literals in the component. This pattern makes handling apostrophes and special characters more predictable across the codebase.
182-182: Improved string interpolation in JSXUsing a template literal inside JSX expression is the proper way to interpolate variables in strings. This makes the code more maintainable and easier to understand.
242-242: Improved string interpolation in JSXUsing a template literal inside JSX expression is the proper way to interpolate variables in strings. This makes the code more maintainable and easier to understand.
src/renderer/src/components/settings/sections/spaces/space-dialogs.tsx (1)
32-32: Improved string interpolation in JSXUsing a template literal inside JSX expression is the proper way to interpolate variables in strings. This makes the code more maintainable and easier to understand.
src/renderer/src/components/onboarding/stages/initial-space/create.tsx (2)
143-143: Style change: Plain text replaced with JSX expression.Similar to the previous change, this is a syntactic modification that maintains the same rendered output.
170-170: Style change: Plain text replaced with JSX expression.Another instance of the same pattern change applied consistently.
src/main/browser/window-manager.ts (1)
1-1: Good cleanup: Removed unused import.Removing the unused
appimport from electron is a positive change for code cleanliness.src/main/modules/extensions/main.ts (1)
43-45: Improved code clarity with explanatory comment.Adding the comment in the empty catch block clearly explains what happens when a session is not found, which makes the error handling path more explicit.
This is a good practice - empty catch blocks should always include comments explaining why exceptions are being silently caught and what the expected behavior is. The comment clarifies that this is an expected path when a session doesn't exist and that a 404 will be returned.
src/main/modules/extensions/permission-warnings.ts (1)
253-255: New exported function provides access to internal mapping.A new function
getReversePermissionMapping()has been added to expose the internalreversePermissionMappingobject.This follows good module design patterns by providing controlled access to internal data structures. The function makes the reverse mapping available to external code that might need it, which increases the module's utility without exposing implementation details directly.
src/main/ipc/session/spaces.ts (4)
1-1: Import cleanup: Removed unused webContents importThe removal of the unused
webContentsimport from "electron" helps to keep the imports clean and focused only on what's being used.
19-21: Improved code clarity with _event parameterConsistently renaming unused event parameters to
_eventor removing them entirely follows good coding practices by explicitly marking parameters that aren't referenced in the function body. This reduces linting warnings and improves code readability.Also applies to: 23-25, 27-29, 31-33, 35-37, 56-58, 60-62
39-46: Verify if _event prefix is needed hereUnlike other handlers that have been updated, this handler still uses the
eventparameter without the underscore prefix. Since the parameter is actively used to get the window from webContents, this is correct, but worth noting for consistency in the review.
48-54: Verify if _event prefix is needed hereLike the previous handler, this one also actively uses the
eventparameter and correctly keeps it without the underscore prefix..prettierignore (1)
1-7: Good configuration for Prettier ignore patternsThe
.prettierignorefile correctly excludes build directories, lock files, configuration files, and public assets that don't require formatting. This will prevent unnecessary formatting operations and avoid potential conflicts with generated or third-party files.src/main/ipc/browser/navigation.ts (2)
19-24: Improved code clarity with _event parameterRenaming unused event parameters to
_eventfollows good coding practices by explicitly marking parameters that aren't referenced in the function body. This change is consistent with the pattern applied throughout the codebase and helps reduce linting warnings.Also applies to: 26-31, 33-47, 49-54
4-17: Verify if _event prefix is needed hereThe first IPC handler on line 4 still uses the
eventparameter without an underscore prefix. This is correct since the event is used to get the webContents sender, but it's worth noting for consistency in the review.src/main/modules/extensions/locales.ts (1)
85-91: Great enhancement for targeted locale support!This new code block improves the function by prioritizing translation to a specified target locale when provided. The implementation follows a clear logic flow: check if target locale exists among available locales, then return the translation immediately if found.
.github/workflows/build-and-release.yml (3)
7-8: Good documentation additionAdding this comment provides helpful context about when the workflow runs.
20-20: Consistent formatting for OS matrix valuesUsing consistent formatting with hyphens for OS names improves readability.
49-64: Improved build organization with dedicated OS-specific stepsThis refactoring creates separate, clearly labeled build steps for each operating system, making the workflow more maintainable and easier to understand. Each step has proper conditional execution and consistent environment variable setup.
src/renderer/src/components/onboarding/screen.tsx (3)
18-18: Good type definition for waypointsAdding this type definition improves code readability and type safety.
30-30: Improved type safety for waypoints arrayUsing the newly created Waypoint type for the waypoints array ensures type consistency and helps catch potential errors at compile time.
289-289: Enhanced type safety for initialShapesAdding explicit typing to the initialShapes array provides better compile-time checking and improves code readability.
src/main/sessions/spaces.ts (4)
5-5: Clean import optimizationRemoving the unused ProfileData import keeps the imports clean and focused.
18-18: Appropriate ESLint directive for schema definitionAdding this ESLint directive to suppress the unused variable warning is appropriate since the schema is used for type inference but not directly referenced in the code.
172-172: Simplified function signatureRemoving the unused prefetchedProfile parameter simplifies the function signature while maintaining the same functionality.
237-237: Consistent function call with updated signatureThis call has been updated to match the simplified function signature, making the code more consistent.
src/main/browser/utility/protocols.ts (4)
89-89: Updated function call to match new signature.The function call to
isDevelopmentServerRunning()has been changed from an awaited promise to a direct synchronous call, which aligns with the updated implementation inhot-reload.tsthat now returns a boolean synchronously based on environment variables rather than performing an asynchronous fetch check.
155-155: Renamed unused parameter to indicate it's not used.The parameter
requesthas been renamed to_requestto indicate it's not used in the function, which is a good practice for code clarity.
173-173: Renamed unused parameter to indicate it's not used.Similar to the previous change, the parameter
requesthas been renamed to_requestto indicate it's not used in the function.
205-205: Renamed unused parameter to indicate it's not used.Consistent with the previous changes, the parameter
requesthas been renamed to_requestto indicate it's not used in the function.src/main/browser/utility/menu/items/spaces.ts (3)
72-72: Renamed unused parameter to indicate it's not used.The callback parameter
matchhas been renamed to_matchto indicate it's not used in the function, improving code clarity.
125-125: Added explicit type annotation for clarity.The variable
iconImageis now explicitly typed asNativeImage | null, which improves type safety and code readability.
155-155: Removed unused parameter from function signature.The exported function
createSpacesMenuno longer accepts a_browserparameter, simplifying the function signature. This is consistent with the function implementation which doesn't use the browser parameter.src/main/index.ts (4)
8-8: Added import for explicit type annotation.The
TabbedBrowserWindowimport has been added to provide proper typing for thewindowvariable later in the file.
81-82: Added ESLint directive before requiring electron-squirrel-startup.An ESLint directive has been added to suppress the TypeScript warning about using
requireinstead ofimport. This is appropriate since electron-squirrel-startup needs to be required directly.
101-101: Renamed unused parameters to indicate they're not used.The event parameter in the second-instance event handler has been renamed from
eventto_eventto indicate it's not used, improving code clarity.
167-167: Improved type safety with explicit type annotation.The
windowvariable is now explicitly typed asTabbedBrowserWindow | null, which helps prevent potential type errors and improves code readability.src/main/browser/tabs/tab.ts (4)
5-5: Removed NEW_TAB_URL import from tab-manager.The import statement has been updated to remove the
NEW_TAB_URLfrom thetab-managerimport, likely because it's no longer used in this file.
330-330: Simplified destructuring by removing unused variables.The destructuring of
thiswas simplified by removing the unused variablesbrowser,profileId, andspaceId, retaining onlywebContentsandwindow: tabbedWindow. This reduces unnecessary variable declarations.
397-398: Added ESLint directive to suppress TypeScript warning.An ESLint directive was added to suppress the TypeScript explicit-any warning on the event listener attachment. This is acceptable since the event types are correctly defined in the
updateEventsconstant above.
758-758: Added explicit return statement for consistency.A
return null;statement was added at the end of the function to ensure a consistent return value, improving code predictability and preventing potential undefined returns.src/main/browser/profile-manager.ts (3)
167-177: LGTM: Parameter simplification improves the API.The removal of the second parameter from
selectTabis a good simplification since the implementation only requires thetabWebContentsparameter to function correctly.
178-183: LGTM: Parameter simplification improves the API.Similar to the
selectTabchange, removing the unnecessary parameter fromremoveTabis a good API simplification.
296-298: LGTM: Explicit return improves code clarity.Adding an explicit
return undefined;statement makes the fallback behavior clearer and is a good practice.eslint.config.mjs (2)
1-5: LGTM: Clean imports using direct module references.The imports are structured well, using direct module references instead of default imports, which is good practice for ESLint plugins.
6-35: LGTM: Well-structured layered configuration.The ESLint configuration is well-structured, using the modern flat config format with clear separation of concerns between different rule sets and file patterns.
.vscode/launch.json (2)
13-16: Verify remote debugging setup
You setREMOTE_DEBUGGING_PORTto9222, but Electron-Vite may require a command-line flag (e.g.,--remote-debugging-port=9222) or explicit forwarding in yourruntimeArgs. Please confirm that the renderer process actually listens on this port for Chrome debugger attachment.
19-24: Confirm renderer debugging attachment settings
ThewebRootis pointed atsrc/renderer, but ensure this matches the built output directory structure (e.g.,dist/renderer) so Chrome DevTools can map source files correctly.electron.vite.config.ts (2)
3-4: Verify Tailwind CSS plugin import
You’re importing from@tailwindcss/vite, which isn’t a standard Vite plugin name. Please confirm that this package exists and is correctly configured inpackage.json.
38-45: Validate renderer plugin configuration
Ensure that the React and Tailwind CSS plugins are correctly applied in the renderer build. If bundling issues arise (missing CSS, React HMR), double-check thatreact()andtailwindcss()are executed in the correct order and with any required options.electron-builder.json (3)
1-71: Good configuration for electron-builder setupThe electron-builder configuration is well structured and comprehensive, covering all necessary aspects for multi-platform builds including:
- Proper app identification with reverse domain name format
- Comprehensive file exclusions to keep builds clean
- Protocol handlers for http/https (essential for a browser)
- File associations for web documents and PDFs
- Platform-specific configurations for Windows, macOS, and Linux
49-52:Details
✅ Verification successful
Verify that entitlements.mac.plist exists
The configuration references an entitlements file for macOS, but it's unclear if this file exists in the repository.
🏁 Script executed:
#!/bin/bash # Check if the entitlements file exists if [ -f "build/entitlements.mac.plist" ]; then echo "✅ Entitlements file exists" else echo "❌ Entitlements file does not exist at build/entitlements.mac.plist" echo "Searching for any entitlements files in the repository..." find . -name "*.plist" | grep -i entitlement fiLength of output: 104
Confirmed: entitlements.mac.plist is present
The entitlements file
build/entitlements.mac.plistexists as referenced inelectron-builder.json. No further changes are needed here.
50-51:Details
❓ Verification inconclusive
Note about disabled macOS notarization
Notarization is currently disabled for macOS builds. While this simplifies development, it may cause security warnings for end users on macOS.
🌐 Web query:
What are the implications of disabling notarization for macOS applications?💡 Result:
Apple's notarization process serves as a security measure for macOS applications distributed outside the App Store. Understanding the implications of disabling it is important for both developers and users.
Disabling Notarization for Testing and Development
For developers working on macOS applications, disabling notarization can be necessary during the development and testing phases. This is because the notarization process adds additional steps that can slow down the development workflow[1]. However, there are several important considerations:
Security Implications
Disabling notarization removes an important security layer designed to protect users from malware. Notarization is essentially a process where Apple scans third-party software for malicious content before allowing it to run on macOS systems[3][6].Methods for Bypassing Notarization
There are several ways to run unnotarized apps on macOS:
- In Privacy & Security settings, users can click "Open Anyway" after receiving the initial warning[4]
- For those frequently testing unnotarized apps, it's possible to disable Gatekeeper entirely, though Apple has made this more complex with recent macOS updates[4]
- Enterprise environments can use MDM profiles to bypass notarization checks for specific applications[6]
Security Considerations
Disabling notarization comes with significant security trade-offs:
Increased Vulnerability
Running unnotarized applications is considered one of the highest risk strategies as it allows potentially malicious software to run without Apple's security screening[4]. In macOS Catalina and later, software that is not notarized is prevented from running by default[9].Security Theater Concerns
Some security experts argue that notarization offers incomplete protection since:
- Malware authors can submit innocent apps for notarization, then deliver malicious updates later[5]
- Notarized malware has been discovered in the wild, showing the system isn't foolproof[8]
- Stolen developer IDs can be used to sign and notarize malicious software[5][6]
User Experience Impact
Disabling notarization affects how users interact with your applications:
Warning Dialogs
Users will encounter multiple warning dialogs when attempting to run unnotarized applications[4]. This may create confusion or concern about the legitimacy of your software.Trust Considerations
For applications distributed to end users, lacking notarization can significantly reduce user trust. Users are increasingly conditioned to expect the security assurance that notarization provides[6].Developer Considerations
Build and Distribution Process
Notarization requires integration with Xcode and Apple's developer infrastructure. Disabling it simplifies the build process but complicates distribution[6].Future Compatibility
Apple continues to tighten security requirements with each macOS release. What's optional today might become mandatory tomorrow, so developing without notarization may create future compatibility issues[7].Development Workflow
For personal projects and testing, disabling notarization can streamline development workflows. However, for any software intended for distribution, incorporating notarization into your CI/CD pipeline is increasingly necessary[1].While disabling notarization might be convenient for development and testing, it presents significant challenges for software distribution and user security. Most security professionals recommend embracing notarization despite its limitations, as it provides an important layer in macOS's defense-in-depth security strategy.
Citations:
- 1: https://forums.developer.apple.com/forums/thread/114138
- 2: https://developer.apple.com/forums/thread/110009
- 3: https://www.sentinelone.com/blog/maco-notarization-security-hardening-or-security-theater/
- 4: https://eclecticlight.co/2024/10/01/living-without-notarization/
- 5: https://mjtsai.com/blog/2019/04/22/the-true-and-false-security-benefits-of-mac-app-notarization/
- 6: https://www.hexnode.com/blogs/mac-notarization-everything-mac-admins-need-to-know/
- 7: https://eclecticlight.co/2023/06/18/last-week-on-my-mac-lies-notarization-and-privacy/
- 8: https://www.jamf.com/blog/stop-notarized-adware-and-protect-your-mac-fleet/
- 9: https://www.malwarebytes.com/blog/news/2020/08/apples-notarization-process-fails-to-protect
- 10: https://developer.apple.com/videos/play/wwdc2019/703/
⚠️ Consider enabling macOS notarization before distributionDisabling notarization (
"notarize": false) in electron-builder.json skips Apple’s malware scan, which can:
- Trigger Gatekeeper warnings or prevent your app from launching on macOS Catalina+
- Expose users to higher security risks
- Undermine user trust in your software
If you only need this for local testing, make sure notarization is re-enabled in your CI/CD pipeline prior to any public release.
• File: electron-builder.json (lines 50–51)
"entitlementsInherit": "build/entitlements.mac.plist", - "notarize": false + "notarize": truesrc/main/browser/utility/hot-reload.ts (2)
21-27: Improved development server detectionThe refactored function simplifies server detection by leveraging environment variables, which is more maintainable than the previous implementation that required HTTP requests.
45-56: Good error handling for missing environment variableThe explicit check for ELECTRON_RENDERER_URL with a clear error message improves developer experience when something is misconfigured.
package.json (2)
13-27: Well-structured scripts for development and buildingThe scripts section is now well-organized with:
- Proper separation of format, lint, and type checking tasks
- Development scripts with watch mode support
- Platform-specific build commands
- A postinstall script for dependency setup
65-69:Details
✅ Verification successful
Check compatibility of React and TypeScript versions
The project is using cutting-edge versions of React (v19) and TypeScript. Ensure these versions are compatible with the rest of your dependencies.
🌐 Web query:
Is React 19 stable and what are the breaking changes from React 18?💡 Result:
React 19 Stability
React 19 is considered stable for production use as of early 2025. The core features have been finalized, and the release is actively recommended for new projects unless specific legacy dependencies prevent upgrading[5][8]. React Server Components, a major addition in React 19, are also considered stable for use and will remain so across minor versions[3].
Major Changes and Breaking Changes from React 18
React 19 builds on the foundation of React 18, delivering significant performance improvements, deeper server-side integration, and a host of new features. However, it also introduces a number of breaking changes and updates that require developers’ attention when migrating from React 18.
Key Breaking Changes
Feature/Behavior React 18 React 19 JSX Transform Supports old and new Requires new JSX transform Rendering APIs ReactDOM.render,hydrateRemoved; use ReactDOM.createRoot,hydrateRootLegacy APIs Supported Some deprecated APIs removed Error Handling Standard error boundaries New error handling methods ( onUncaughtError,onCaughtError)refPropsforwardReffor function componentsrefcan be passed as a standard propPropTypes (React Native) Supported Removed Details:
- JSX Transform Requirement: React 19 mandates the use of the new JSX transform, discontinuing support for the legacy transform. This changes how JSX is compiled, with the new approach being more efficient and future-proof[6].
- Removal of Legacy Rendering APIs: Classic APIs like
ReactDOM.renderandReactDOM.hydrateare no longer available. All rendering should useReactDOM.createRootandReactDOM.hydrateRoot[6].- Error Handling Enhancements: New root-level error handling callbacks (
onUncaughtError,onCaughtError) have been introduced, refining how applications catch and log errors[6].- PropTypes Removal: In React Native, PropTypes have been removed, requiring developers to use alternative validation, such as TypeScript or custom validators[8].
- Passing
refas a Prop: Functional components can now acceptrefdirectly as a prop, eliminating the need forforwardRefin many scenarios and simplifying component code[8].- Legacy APIs: Some other legacy APIs and behaviors that were previously deprecated have now been fully removed, so code audits during migration are necessary[6][8].
New Features and Improvements
- React Compiler: An experimental compiler that automatically optimizes components, reducing the need for manual memoization and enhancing performance[6][9].
- Server Components: New architecture allowing server-side rendering of components, improving performance, SEO, and bundle size[1][3][7][9].
- Async Actions and Transitions: Native support for async transitions, including automatic management of pending states, optimistic updates, and error handling[3][8].
- Expanded Concurrent Rendering: Async rendering and automatic batching have been further improved, boosting responsiveness for complex UIs[6][7][9].
- Advanced Hydration: Smarter hydration strategies for server-side rendering (SSR), leading to faster and more reliable initial loads[7][9][10].
- New and Improved Hooks: Introduction of hooks like
useActionState,useFormStatus,useOptimistic,useServerState, and enhancements to existing hooks for smoother data and UI management[8][9].- Developer Tools: Improved debugging and profiling tools for deeper insights into component performance[1][7].
Migration Considerations
When upgrading to React 19 from React 18:
- Update your JSX compilation setup to use the new transform.
- Refactor rendering logic to replace deprecated APIs with their modern equivalents.
- Adjust error boundary implementations to leverage new error handling events.
- For React Native apps, remove any legacy usage of PropTypes.
- Audit third-party dependencies for React 19 compatibility, especially if you rely on packages that hook into React’s internal APIs[6][8].
Conclusion
React 19 is stable and recommended for most new projects. It provides substantial improvements in performance, developer experience, and server-side capabilities. However, migration from React 18 does require attention to breaking changes—especially with JSX transforms, rendering APIs, and certain legacy methods. Thoroughly testing key flows and refactoring deprecated patterns are essential steps for a smooth upgrade[6][9].
Citations:
- 1: https://dev.to/sovannaro/react-18-vs-react-19-key-differences-to-know-for-2025-1614
- 2: https://dev.to/holasoymalva/why-i-decided-to-stop-working-with-reactjs-in-2025-4d1l
- 3: https://react.dev/blog/2024/12/05/react-19
- 4: https://www.youtube.com/watch?v=rwC7HY8_U_g
- 5: https://javascript.plainenglish.io/how-to-set-up-reactjs-19-for-production-in-2025-27f3115b7ac3
- 6: https://dev.to/manojspace/react-19-vs-react-18-performance-improvements-and-migration-guide-5h85
- 7: https://blog.nashtechglobal.com/react-19-vs-react-18-key-differences/
- 8: https://reactnative.dev/blog/2025/02/19/react-native-0.78
- 9: https://www.technaureus.com/blog-detail/react-19-vs-react-18-whats-changed-why-it-matters
- 10: https://pattemdigital.com/insight/difference-between-react-18-and-react-19/
🏁 Script executed:
#!/bin/bash # Check the TypeScript version in package.json to ensure compatibility with React 19's new JSX transform rg '"typescript":' -n package.jsonLength of output: 67
React 19 and TypeScript 5.8.3 compatibility confirmed
Both React 19 (stable for production) and TypeScript ^5.8.3 fully support the new JSX transform required in React 19—no changes to your package.json are needed. To complete the migration, please ensure:
• tsconfig.json uses the new JSX setting:
"jsx": "react-jsx"
• All rendering calls have been updated to the new APIs:
ReactDOM.createRoot/hydrateRootinstead ofReactDOM.render/hydrate
• Any error boundaries leverage the new hooks (onUncaughtError,onCaughtError)
• Third-party plugins (e.g. @vitejs/plugin-react) are on recent versions that support React 19’s JSX transformWith these in place, you can safely proceed on React 19 + TS 5.8.3.
src/main/browser/tabs/tab-context-menu.ts (1)
6-30: Improved type safety with explicit interfacesAdding explicit interfaces for
NavigationHistoryandMenuActionsimproves type safety and makes the code more maintainable. The interface design properly captures the structure and behavior of these objects.src/preload/index.ts (7)
9-30: Improved type safety with explicit API interface importsThe addition of explicit interface imports from the shared flow interfaces provides stronger type safety and clearer API contracts. This approach ensures that the preload script's API implementations adhere to the expected signatures defined in the shared interfaces.
107-110: ESLint disables have been added for unavoidableanyusageThe ESLint disable comments have been strategically added to acknowledge places where any types are unavoidable in the IPC communication layer. This is an acceptable approach when dealing with cross-process communication in Electron.
161-161: Well-typed API implementation objects aligned with interface definitionsThe API implementations are now properly typed with their corresponding interface types from the shared interfaces. This ensures type consistency between the preload script and the main process handlers.
Also applies to: 174-174, 199-199, 206-206, 225-225, 247-247, 266-266, 303-303, 332-332, 348-348, 355-355, 365-365, 375-375, 385-385, 401-401, 411-411
178-178: Improved type safety for event callback in onDataUpdatedThe callback parameter now has a proper type annotation that matches the WindowTabsData interface, ensuring type safety when handling tab data events.
415-415: Improved type safety for event callback in onUpdatedThe callback parameter now has a proper type annotation that includes the profileId and extensions array with SharedExtensionData type, ensuring type safety when handling extension updates.
184-186:Details
✅ Verification successful
Parameter order change in newTab method
The implementation now matches the interface definition with optional parameters in the correct order. The code organization is cleaner and more maintainable.
🏁 Script executed:
#!/bin/bash # Check if there are any usages of the old parameter order in the codebase # This could indicate places that need to be updated rg -A 2 "flow\.tabs\.newTab\(" --type=ts --type=tsxLength of output: 81
Let’s retry searching usages without relying on the built-in types:
🏁 Script executed:
#!/bin/bash # Search for any calls to flow.tabs.newTab in .ts and .tsx files rg -A 2 "flow\.tabs\.newTab\(" --glob '*.ts' --glob '*.tsx'Length of output: 685
Parameter order change in
newTabmethod — all call sites verified
- Inspected usages in the codebase:
- src/renderer/src/lib/omnibox/omnibox.ts –
flow.tabs.newTab("flow://extensions", true)andflow.tabs.newTab(url, true)- src/renderer/src/components/browser-ui/browser-action.tsx –
flow.tabs.newTab("flow://extensions", true)- All calls pass
(url, isForeground)in the updated order; no breaking changes detected.
210-212:Details
✅ Verification successful
Parameter order change in goTo method
The parameters have been rearranged to make tabId optional. This matches the FlowNavigationAPI interface definition.
🏁 Script executed:
#!/bin/bash # Check if there are any usages of the old parameter order in the codebase # This could indicate places that need to be updated rg -A 2 "flow\.navigation\.goTo\(" --type=ts --type=tsxLength of output: 85
🏁 Script executed:
#!/bin/bash # Retry searching for any usages of flow.navigation.goTo across TS and TSX files rg -A 2 "flow\\.navigation\\.goTo\\(" -g "*.ts" -g "*.tsx" || trueLength of output: 264
Parameter order change in goTo method verified
All calls toflow.navigation.goTonow match the updated(url: string, tabId?: number)signature.
- src/renderer/src/lib/omnibox/omnibox.ts:
flow.navigation.goTo(url);correctly passes only the URL argument.
src/renderer/src/components/settings/sections/general/basic-settings-cards.tsx
Show resolved
Hide resolved
1 participant
Info
Migrated the entire codebase to electron-vite for better dev experience & electron-builder support!
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
.gitignoreand related configuration files.Chores
Documentation