Chore/update electron builder #9120
Conversation
Bumps [electron](https://github.com/electron/electron) from 30.5.1 to 35.7.5. - [Release notes](https://github.com/electron/electron/releases) - [Changelog](https://github.com/electron/electron/blob/main/docs/breaking-changes.md) - [Commits](electron/electron@v30.5.1...v35.7.5) --- updated-dependencies: - dependency-name: electron dependency-version: 35.7.5 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]>
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughElectron and electron-builder versions upgraded across the project (^30.0.1 to ^38.1.2 and ^24.13.3 to 26.0.3). Runtime dependencies added ( Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Greptile Summary
This PR updates Electron Builder from version 24.13.3 to 25.1.8 across the entire monorepo and introduces a new dependency patching system for local packages. The changes affect all Electron-based applications (desktop, agent, desktop-timer, server variants) and include:
Core Updates:
- Electron Builder upgraded from v24 to v25 (major version)
- Electron version references updated from 30.x to 35.7.5 across build scripts
better-sqlite3updated from 9.6.0 to 12.2.0 in the core package
Dependency Management Restructuring:
- Workspaces configuration removed from multiple package.json files
- New local dependency patching system introduced via
.scripts/electron-deps/patch-local-deps.ts - New
patch:*:local:depsandlocal:depsscripts added to automate dependency rewriting - Dependencies now use explicit
file:references instead of workspace management
New Dependencies Added:
@gauzy/commonpackage added to multiple applications@gauzy/plugin-integration-activepiecesintegration plugincall-bind-apply-helpersandcheerio-selectpackages
Electron Event Handler Modernization:
- Updated
window-all-closedevent handler to remove Event parameter andevent.preventDefault()call - Simplified quit behavior: allows normal quit on Windows/Linux, maintains dock hiding on macOS
The dependency patching system addresses a common monorepo issue where Electron builds might reference outdated npm versions instead of locally built packages. The script automatically rewrites @gauzy scoped dependencies to use file: paths pointing to dist/packages, ensuring Electron applications always bundle the most current local code.
PR Description Notes:
- The PR template checkboxes are not completed
- Missing explanation of changes and their value as required by the template
Confidence score: 2/5
- This PR requires careful review due to multiple breaking changes and complex dependency restructuring
- Score lowered due to major version updates, untested build configurations, and several code quality issues in the new patching script
- Pay close attention to the new patch-local-deps.ts script which contains syntax errors and type safety issues that will cause runtime failures
Context used:
Context - Always check the boxes in the PR template and provide all requested information, or the PR may be closed without comment. (link)
Context - Avoid using 'any' type in TypeScript. Instead, refine the type of variables or update the relevant interface to ensure type safety. (link)
15 files reviewed, 7 comments
|
@syns2191 see more AI suggestions please |
dependabot
bot
force-pushed
the
dependabot/npm_and_yarn/electron-35.7.5
branch
from
d497a5d to
b1a9979
Compare
evereq
changed the base branch from
dependabot/npm_and_yarn/electron-35.7.5
to
develop
|
@syns2191 I did "changed the base branch from dependabot/npm_and_yarn/electron-35.7.5 to develop", hope it's OK? This PR should target develop branch and if that other PR that update only part of electron should be merged, please change THAT PR target to be this feature branch, i.e. for PR from bot, change target to be Basically, can you make sure ALL required changes are in one PR and it's this PR please? Also, it feels this PR might make a LOT of issues with builds for all our apps, so it will be great to get @adkif involved to test everything on his Mac before we can merge this PR. But FIRST, let's make this PR to be fully ready and include all changes etc. |
The `build:desktop-timer:mac:quick` script now includes `build:desktop-timer` and `patch:desktop-timer:local:deps` to ensure all necessary prerequisites are met before building the Electron package. The `prepare:desktop:dev` script was removed as it is no longer used for desktop development.
|
|
@evereq it's ok you change the target branch to develop. you can close the other branch / dependabot pr. all the upgrade electron and electron-builder is in this PR. |
There was a problem hiding this comment.
Greptile Overview
Summary
This review covers only the changes made since the last review, not the entire PR. The changes implement a comprehensive Electron ecosystem update across the Ever Gauzy monorepo, upgrading Electron from version 30.0.1 to 35.7.5 and electron-builder from 24.13.3 to 25.1.8. The PR introduces a new dependency patching system through the `patch-local-deps.ts` script and corresponding `patch:*:local:deps` commands integrated into all build workflows.The update addresses workspace dependency management by removing workspace configurations from nested package.json files and introducing file-based references for local packages. New dependencies like @gauzy/common, @gauzy/plugin-integration-activepieces, call-bind-apply-helpers, and cheerio-select are added across multiple applications, indicating expanded functionality and modernized tooling requirements.
The changes maintain version consistency across all Electron-based applications (desktop, agent, desktop-timer, server-api, server-mcp) ensuring uniform behavior and compatibility. The new patching system helps resolve local dependency issues that commonly arise in monorepo setups with Electron builds, while the Electron version upgrade brings security improvements, performance enhancements, and access to newer Chromium features.
PR Description Notes:
- Both checkboxes in the PR template remain unchecked
- The explanation of changes and value-add is missing from the PR description
Changed Files
| Filename | Score | Overview |
|---|---|---|
| packages/desktop-activity/package.json | 4/5 | Updates Electron from v30.0.1 to v35.7.5 in devDependencies |
| packages/desktop-lib/package.json | 3/5 | Major updates to better-sqlite3 (v9→v12) and Electron (v30→v35) |
| apps/desktop/package.json | 4/5 | Updates Electron to v35.7.5 and electron-builder to v25.1.8 |
| packages/core/package.json | 3/5 | Major version bump for better-sqlite3 from v9.6.0 to v12.2.0 |
| apps/server-mcp/package.json | 4/5 | Updates Electron and electron-builder versions for MCP server |
| apps/agent/src/package.json | 4/5 | Removes workspaces config and adds new dependencies with formatting changes |
| apps/desktop-timer/package.json | 3/5 | Major Electron version upgrade from v30 to v35 with electron-builder update |
| apps/server/package.json | 3/5 | Updates Electron and electron-builder with major version jumps |
| .scripts/electron-deps/patch-local-deps.ts | 4/5 | New TypeScript script for patching local package dependencies |
| apps/server/src/package.json | 4/5 | Removes workspaces and adds new dependencies for server build |
| apps/server-api/package.json | 3/5 | Updates Electron and electron-builder for API server package |
| apps/desktop/src/package.json | 4/5 | Removes workspaces configuration and adds new package dependencies |
| packages/desktop-window/package.json | 4/5 | Updates Electron version for window management package |
| apps/agent/src/main/init/app.ts | 5/5 | Removes unnecessary Event parameter and preventDefault from window event handler |
| apps/desktop-timer/src/package.json | 4/5 | Structural changes including workspaces removal and new dependencies |
| apps/server-api/src/package.json | 4/5 | Removes workspaces and adds new Gauzy package dependencies |
| apps/agent/package.json | 4/5 | Updates Electron and electron-builder versions for agent application |
| package.json | 2/5 | Major Electron ecosystem update with new patching system across all apps |
| packages/desktop-ui-lib/package.json | 3/5 | Major Electron version update for desktop UI library package |
Confidence score: 2/5
- This PR involves major version upgrades across critical dependencies that require extensive testing across multiple platforms
- Score reflects the high risk associated with simultaneous major updates to Electron (5 versions), electron-builder, and better-sqlite3 (3 versions) across the entire codebase
- Pay close attention to package.json files, the new patch-local-deps.ts script, and all Electron-based applications for runtime compatibility issues
Context used:
Context - Always check the boxes in the PR template and provide all requested information, or the PR may be closed without comment. (link)
Context - Avoid using 'any' type in TypeScript. Instead, refine the type of variables or update the relevant interface to ensure type safety. (link)
19 files reviewed, no comments
| "@gauzy/desktop-activity": "^0.1.0", | ||
| "get-windows": "^9.2.3", | ||
| "better-sqlite3": "9.6.0", | ||
| "better-sqlite3": "12.2.0", |
There was a problem hiding this comment.
i am on progress test all apps.
|
@syns2191 please rebase on top of latest on develop and fix merge conflicts etc |
…date-electron-builder
|
All alerts resolved. Learn more about Socket for GitHub. This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
…date-electron-builder
…date-electron-builder
…date-electron-builder
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 7421875 | Triggered | Google API Key | 522a20b | .deploy/k8s/k8s-manifest.demo.yaml | View secret |
| 7461871 | Triggered | Generic High Entropy Secret | 522a20b | .deploy/k8s/k8s-manifest.demo.yaml | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
…m:ever-co/ever-gauzy into fix/build-all-desktop
Hi @evereq, I have already fix the conflict. so now i just make changes only in package.json files. i have test build in local and run the all desktop app (except mcp server) |
…date-electron-builder
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
* fix: desktop sentry bug report page * fix(invoice): add UseValidationPipe to pagination endpoint for SQLite boolean compatibility * Merge pull request #9120 from ever-co/chore/update-electron-builder Chore/update electron builder --------- Co-authored-by: syns2191 <[email protected]> Co-authored-by: samuelmbabhazi <[email protected]>
Greptile OverviewGreptile SummaryThis PR upgrades Electron from version 30.0.1 to 38.1.2 and electron-builder from 24.13.3 to 26.0.3, representing a major version jump. All build scripts across desktop, desktop-timer, agent, and server applications were updated to use Electron 38.2.2. Key changes:
Critical issue:
Confidence Score: 2/5
Important Files ChangedFile Analysis
Sequence DiagramsequenceDiagram
participant Dev as Developer
participant PM as Package Manager
participant EB as Electron Builder
participant App as Electron App
Dev->>PM: Update package.json dependencies
Note over PM: electron: 30.0.1 → 38.1.2<br/>electron-builder: 24.13.3 → 26.0.3
Dev->>PM: Update build scripts
Note over PM: electronVersion: 30.0.1 → 38.2.2<br/>across all platforms
Dev->>PM: yarn install
PM->>PM: Resolve dependencies
PM->>PM: Update yarn.lock
Dev->>App: Update event handlers
Note over App: Remove event.preventDefault()<br/>from window-all-closed
Dev->>EB: Run build scripts
EB->>EB: Use Electron 38.2.2
EB->>EB: Package with electron-builder 26.0.3
EB-->>Dev: Build artifacts
Note over App: Changed behavior:<br/>App quits on window close<br/>instead of staying in dock
|
| app.on('window-all-closed', () => { | ||
| // On OS X it is common for applications and their menu bar | ||
| // to stay active until the user quits explicitly with Cmd + Q | ||
| event.preventDefault(); | ||
| if (process.platform === 'darwin') { | ||
| app.dock.hide(); | ||
| } |
There was a problem hiding this comment.
logic: Removing event.preventDefault() changes app quit behavior. Without it, the app will quit when all windows close on all platforms. The original code prevented default quit behavior, then selectively hid the dock on macOS. Now the app will quit completely instead of staying in the dock. This breaks the "stay active until user quits explicitly with Cmd + Q" behavior mentioned in the comment.
If this change is intentional due to Electron 38 API changes, the comment should be updated. Otherwise, restore the event.preventDefault() or implement alternative logic to prevent app quit on window close.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/agent/src/main/init/app.ts
Line: 307:312
Comment:
**logic:** Removing `event.preventDefault()` changes app quit behavior. Without it, the app will quit when all windows close on all platforms. The original code prevented default quit behavior, then selectively hid the dock on macOS. Now the app will quit completely instead of staying in the dock. This breaks the "stay active until user quits explicitly with Cmd + Q" behavior mentioned in the comment.
If this change is intentional due to Electron 38 API changes, the comment should be updated. Otherwise, restore the `event.preventDefault()` or implement alternative logic to prevent app quit on window close.
How can I resolve this? If you propose a fix, please make it concise.![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/agent/src/main/init/app.ts (1)
307-313: Removal of event.preventDefault() contradicts documented design intent from PR 8874.Previous work explicitly documented that this handler should "prevent closing on all platforms when all windows are closed" with
event.preventDefault()called "intentionally unconditionally." Removing this call reverts the app to Electron's default behavior on Windows/Linux, causing it to quit when all windows close rather than remain active.The current code only manages macOS dock visibility and does not prevent application closure on other platforms. Either restore the
event.preventDefault()call and update the comment to reflect cross-platform behavior, or document why this design change was intentional.
♻️ Duplicate comments (4)
apps/agent/package.json (1)
28-28: Verify agent app builds and runs with electron 38.1.2 and electron-builder 26.0.3.Per PR comments, the agent app was tested locally. Confirm that:
- Desktop builds complete without errors
- Built app runs successfully
- No runtime issues with the new Electron version
Also applies to: 30-30
apps/desktop/package.json (1)
28-29: Confirm desktop app tested for all features with Electron 38.1.2.The desktop app is mission-critical. Per PR comments, local testing was performed. Ensure testing covered:
- Activity tracking (@gauzy/desktop-activity with better-sqlite3 12.2.0)
- Screenshots and system integration
- Tray/menu functionality with custom-electron-titlebar
- Auto-update with electron-updater
package.json (1)
400-410:⚠️ CRITICAL: Missingpatch:gauzy-mcp-server:local:depsscript invocation.The
build:gauzy-mcp-server:*commands are missing the local dependency patch step that all other electron build targets include. This will cause electron-builder to attempt fetching unpublished@gauzy/*packages from npm, resulting in build failures once caches expire.All other electron build scripts (desktop, desktop-timer, gauzy-server, gauzy-api-server, agent) correctly invoke
patch:*:local:depsbefore electron-builder, but the MCP server builds omit this critical step.Add a
patch:gauzy-mcp-server:local:depsscript and invoke it in everybuild:gauzy-mcp-server:*command (lines 400-410) immediately before theyarn electron-buildercall, matching the pattern used by other targets.+"patch:gauzy-mcp-server:local:deps": "yarn run local:deps --dist=dist --scope=@gauzy --apps=gauzy-mcp-server",Then update each build command:
-"build:gauzy-mcp-server:windows": "cross-env NODE_ENV=production NODE_OPTIONS=--max-old-space-size=12288 yarn run build:gauzy-mcp-server && npm config set cache .cache && yarn electron-builder -c.electronVersion=38.2.2 -c.extraMetadata.author.name=Ever build --windows --project dist/apps/server-mcp", +"build:gauzy-mcp-server:windows": "cross-env NODE_ENV=production NODE_OPTIONS=--max-old-space-size=12288 yarn run build:gauzy-mcp-server && yarn run patch:gauzy-mcp-server:local:deps && npm config set cache .cache && yarn electron-builder -c.electronVersion=38.2.2 -c.extraMetadata.author.name=Ever build --windows --project dist/apps/server-mcp",Apply the same patch addition before
yarn electron-builderin all otherbuild:gauzy-mcp-server:*variants (lines 401, 402, 403, 404, 405, 406, 407).apps/agent/src/package.json (1)
138-139: Verify the newly added external dependenciescall-bind-apply-helpersandcheerio-select.These packages are added in both the desktop and agent apps without explanation in the PR description or AI summary. Before merging, confirm:
- These are legitimate npm packages and not typos or unintended entries.
- They are required by electron-builder 26 or its transitive dependencies (not manual polyfills).
- They have been tested with electron-builder 26 and the upgraded Electron version.
- No security or compatibility concerns with the specified versions (^1.0.2 and ^2.1.0).
To verify, search the package repository and confirm these packages exist:
What is call-bind-apply-helpers npm package used for?What is cheerio-select npm package used for?Alternatively, check whether these appear as transitive dependencies of electron-builder 26 in your lock file.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (19)
.cspell.json(1 hunks)apps/agent/package.json(1 hunks)apps/agent/src/main/init/app.ts(1 hunks)apps/agent/src/package.json(1 hunks)apps/desktop-timer/package.json(1 hunks)apps/desktop-timer/src/package.json(1 hunks)apps/desktop/package.json(1 hunks)apps/desktop/src/package.json(2 hunks)apps/server-api/package.json(1 hunks)apps/server-api/src/package.json(2 hunks)apps/server-mcp/package.json(1 hunks)apps/server-mcp/src/package.json(1 hunks)apps/server/package.json(1 hunks)apps/server/src/package.json(2 hunks)package.json(9 hunks)packages/core/package.json(1 hunks)packages/desktop-activity/package.json(1 hunks)packages/desktop-lib/package.json(2 hunks)packages/desktop-ui-lib/package.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
**/[a-z0-9-]*.{ts,html,css,scss}
📄 CodeRabbit inference engine (.cursor/rules/angular.mdc)
Separate words in Angular file names with hyphens and use lowercase (e.g., user-profile.ts, user-profile.html, user-profile.css)
Files:
apps/agent/src/main/init/app.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/angular.mdc)
**/*.ts: Match file names to the primary TypeScript identifier within (class/function) and avoid generic names like helpers.ts or utils.ts
Prefer the inject() function over constructor parameter injection for Angular dependencies
Group Angular-specific properties (injections, inputs, outputs, queries) before class methods in components/directives
Mark class members used only by the component’s template as protected to avoid leaking public API
Mark Angular-initialized members (input/model/output and queries) as readonly; for decorator APIs, apply to outputs and queries (not inputs)
Keep lifecycle hook methods simple; move logic into well‑named private methods and call them from the hook
Implement Angular lifecycle hook interfaces (e.g., OnInit) to ensure correct hook naming
Use a consistent, project-specific selector prefix for components/directives and never use the ng prefix
For directive attribute selectors, use lowercase, dash-case attributes (e.g., button[yt-upload])
Files:
apps/agent/src/main/init/app.ts
**/*.{ts,html,css,scss}
📄 CodeRabbit inference engine (.cursor/rules/angular.mdc)
Use the same base file name for a component’s TypeScript, template, and style files (e.g., user-profile.ts/html/css)
Files:
apps/agent/src/main/init/app.ts
**/*.{html,ts}
📄 CodeRabbit inference engine (.cursor/rules/angular.mdc)
Name event handlers for what they do (e.g., saveUserData) instead of the triggering event (e.g., handleClick)
Files:
apps/agent/src/main/init/app.ts
🧠 Learnings (31)
📓 Common learnings
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9068
File: apps/server-mcp/tsconfig.electron.json:17-18
Timestamp: 2025-07-29T21:00:16.321Z
Learning: In the ever-co/ever-gauzy project's apps/server-mcp/tsconfig.electron.json, the "electron" type should be removed from the types array because the project no longer uses Electron APIs and has moved to a Node.js-only architecture. Adding "electron" types causes build errors in their current setup, so only "node" types should be included.
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9082
File: apps/agent/src/package.json:142-146
Timestamp: 2025-08-02T12:37:34.556Z
Learning: In the ever-co/ever-gauzy project, during major Sentry migrations (like v7 to v9), sentry/core is explicitly added as a dependency to individual package.json files to prevent version mismatches and ensure all packages use the same core version, even if it might seem redundant due to workspace hoisting.
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9153
File: apps/mcp-auth/package.json:33-37
Timestamp: 2025-10-19T17:11:14.709Z
Learning: In the ever-co/ever-gauzy project, the apps/mcp-auth/package.json intentionally includes local devDependencies (types/node@^22.14.0, rimraf@^3.0.2, typescript@^5.8.3) that differ from the workspace root versions. This configuration is correct for the mcp-auth app's code structure and should not be deduplicated or removed.
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9082
File: apps/agent/src/package.json:142-146
Timestamp: 2025-08-02T12:37:35.872Z
Learning: User samuelmbabhazi explicitly adds sentry/core dependencies across package.json files in the ever-co/ever-gauzy monorepo to avoid package version mismatches and ensure consistent version resolution, particularly during major Sentry version migrations. This is their preferred approach for dependency management over relying on workspace hoisting.
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9082
File: apps/desktop/package.json:60-63
Timestamp: 2025-08-02T12:37:43.958Z
Learning: In the ever-co/ever-gauzy project, sentry/core is explicitly declared as a dependency in package.json files (even when it could be pulled transitively) to prevent package version mismatches and ensure consistent Sentry core versions across all applications in the monorepo. This is a deliberate dependency management strategy by samuelmbabhazi to maintain version consistency.
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9082
File: apps/desktop-timer/src/package.json:147-151
Timestamp: 2025-08-02T12:37:40.134Z
Learning: In the ever-co/ever-gauzy project, user samuelmbabhazi explicitly adds sentry/core as a direct dependency alongside other Sentry packages (like sentry/node, sentry/electron, sentry/profiling-node) to avoid package version mismatches and ensure all Sentry packages use the same core version. This is their deliberate dependency management strategy, especially during major Sentry version migrations.
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9153
File: apps/mcp-auth/project.json:8-24
Timestamp: 2025-10-19T17:12:49.582Z
Learning: In the ever-co/ever-gauzy project, the apps/mcp-auth/project.json build configuration with `generatePackageJson: true` is correct for the mcp-auth app's code structure. The NX build executor properly handles dependency resolution in this monorepo setup, and no modifications to the build target configuration are needed.
Learnt from: syns2191
Repo: ever-co/ever-gauzy PR: 9033
File: packages/desktop-activity/src/lib/activity-window.ts:113-120
Timestamp: 2025-07-11T01:30:50.701Z
Learning: In the ever-gauzy codebase, the build system compiles all static import statements to require statements. When working with ESM-only modules like 'get-windows', the Function constructor approach with dynamic import is used to bypass build-time transformations, as seen in packages/desktop-activity/src/lib/activity-window.ts.
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9153
File: apps/mcp-auth/tsconfig.spec.json:6-6
Timestamp: 2025-10-19T17:45:01.123Z
Learning: In the ever-co/ever-gauzy project, the apps/mcp-auth/tsconfig.spec.json intentionally has moduleResolution set to "node10". This configuration is correct for the mcp-auth app's code structure and should not be changed to "node16" or "nodenext".
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is successfully used across multiple core files (api-client.ts, auth-manager.ts, mcp-server.ts, etc.) without any conditional logic or fallbacks. This proves electron-log works reliably in both Electron and standalone Node.js contexts within this codebase. The files using console.error (employees.ts, tasks.ts, daily-plan.ts) are inconsistent outliers that should use log.error for consistency.
📚 Learning: 2025-07-29T21:00:16.321Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9068
File: apps/server-mcp/tsconfig.electron.json:17-18
Timestamp: 2025-07-29T21:00:16.321Z
Learning: In the ever-co/ever-gauzy project's apps/server-mcp/tsconfig.electron.json, the "electron" type should be removed from the types array because the project no longer uses Electron APIs and has moved to a Node.js-only architecture. Adding "electron" types causes build errors in their current setup, so only "node" types should be included.
Applied to files:
apps/server/package.jsonapps/server-mcp/package.jsonapps/agent/package.jsonpackages/desktop-activity/package.jsonpackages/desktop-lib/package.jsonapps/server-api/package.jsonapps/desktop-timer/src/package.jsonapps/desktop/package.jsonapps/agent/src/main/init/app.tsapps/desktop-timer/package.jsonpackages/desktop-ui-lib/package.jsonapps/server-api/src/package.jsonapps/server-mcp/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.jsonpackage.jsonapps/agent/src/package.json
📚 Learning: 2025-10-19T17:11:14.709Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9153
File: apps/mcp-auth/package.json:33-37
Timestamp: 2025-10-19T17:11:14.709Z
Learning: In the ever-co/ever-gauzy project, the apps/mcp-auth/package.json intentionally includes local devDependencies (types/node@^22.14.0, rimraf@^3.0.2, typescript@^5.8.3) that differ from the workspace root versions. This configuration is correct for the mcp-auth app's code structure and should not be deduplicated or removed.
Applied to files:
apps/server/package.jsonpackages/core/package.jsonapps/server-mcp/package.jsonapps/agent/package.jsonpackages/desktop-activity/package.jsonpackages/desktop-lib/package.jsonapps/server-api/package.jsonapps/desktop-timer/src/package.jsonapps/desktop/package.jsonapps/desktop-timer/package.jsonpackages/desktop-ui-lib/package.jsonapps/server-api/src/package.jsonapps/server-mcp/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.jsonpackage.jsonapps/agent/src/package.json
📚 Learning: 2025-07-31T11:10:53.946Z
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9076
File: apps/desktop-timer/package.json:56-59
Timestamp: 2025-07-31T11:10:53.946Z
Learning: sentry/electron package follows its own versioning scheme where v6.8.0 is the latest version and is fully compatible with Sentry core v9. The version numbers don't need to match across all Sentry packages as they have different release cycles.
Applied to files:
apps/server/package.jsonapps/server-mcp/package.jsonapps/server-api/package.json
📚 Learning: 2025-07-31T11:17:31.456Z
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9076
File: apps/server/package.json:54-54
Timestamp: 2025-07-31T11:17:31.456Z
Learning: sentry/electron package version 6.8.0 is the latest version available on npm and is fully compatible with Sentry core v9. This corrects previous information suggesting 6.5.0 was the latest version.
Applied to files:
apps/server/package.jsonapps/server-api/package.json
📚 Learning: 2025-07-31T11:10:53.946Z
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9076
File: apps/desktop-timer/package.json:56-59
Timestamp: 2025-07-31T11:10:53.946Z
Learning: sentry/electron package v6.x is fully compatible with Sentry core v9 because it internally uses the Sentry JavaScript SDK v9. The sentry/electron package follows its own versioning scheme (v6.x) while maintaining compatibility with Sentry JavaScript SDK v9, so version numbers don't need to match across all Sentry packages.
Applied to files:
apps/server/package.jsonapps/server-mcp/package.jsonapps/server-api/package.jsonpackage.json
📚 Learning: 2025-08-02T12:37:34.556Z
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9082
File: apps/agent/src/package.json:142-146
Timestamp: 2025-08-02T12:37:34.556Z
Learning: In the ever-co/ever-gauzy project, during major Sentry migrations (like v7 to v9), sentry/core is explicitly added as a dependency to individual package.json files to prevent version mismatches and ensure all packages use the same core version, even if it might seem redundant due to workspace hoisting.
Applied to files:
packages/core/package.jsonapps/desktop-timer/src/package.jsonapps/server-api/src/package.jsonapps/server-mcp/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.jsonapps/agent/src/package.json
📚 Learning: 2025-07-25T05:08:34.515Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is used consistently across most tool files for logging, but some files (employees.ts, tasks.ts, daily-plan.ts) still use console.error creating an inconsistency. The electron-log library works in both Electron and Node.js contexts, so it's safe to use throughout the shared package for consistent logging behavior.
Applied to files:
apps/server-mcp/package.jsonapps/server-api/package.jsonapps/agent/src/main/init/app.tspackage.json
📚 Learning: 2025-10-19T17:12:49.582Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9153
File: apps/mcp-auth/project.json:8-24
Timestamp: 2025-10-19T17:12:49.582Z
Learning: In the ever-co/ever-gauzy project, the apps/mcp-auth/project.json build configuration with `generatePackageJson: true` is correct for the mcp-auth app's code structure. The NX build executor properly handles dependency resolution in this monorepo setup, and no modifications to the build target configuration are needed.
Applied to files:
apps/server-mcp/package.jsonapps/desktop-timer/src/package.jsonapps/server-api/src/package.jsonapps/server-mcp/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.jsonpackage.jsonapps/agent/src/package.json
📚 Learning: 2025-07-25T05:08:34.515Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9029
File: packages/mcp-server/src/lib/tools/employees.ts:78-600
Timestamp: 2025-07-25T05:08:34.515Z
Learning: In the ever-co/ever-gauzy packages/mcp-server shared package, electron-log is successfully used across multiple core files (api-client.ts, auth-manager.ts, mcp-server.ts, etc.) without any conditional logic or fallbacks. This proves electron-log works reliably in both Electron and standalone Node.js contexts within this codebase. The files using console.error (employees.ts, tasks.ts, daily-plan.ts) are inconsistent outliers that should use log.error for consistency.
Applied to files:
apps/server-mcp/package.jsonapps/server-api/package.jsonapps/agent/src/main/init/app.tspackage.json
📚 Learning: 2025-07-30T15:25:57.253Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9072
File: packages/mcp-server/src/lib/tools/daily-plan.ts:4-6
Timestamp: 2025-07-30T15:25:57.253Z
Learning: In the ever-co/ever-gauzy packages/mcp-server, when importing from the external SDK modelcontextprotocol/sdk, the .js extension should be kept in import paths (e.g., 'modelcontextprotocol/sdk/server/mcp.js') to ensure the MCP server app builds successfully. This applies to all files using the modelcontextprotocol/sdk package, while internal/relative imports should not use the .js extension.
Applied to files:
apps/server-mcp/package.jsonapps/server-mcp/src/package.jsonapps/server/src/package.jsonpackage.json
📚 Learning: 2025-07-31T11:17:31.456Z
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9076
File: apps/server/package.json:54-54
Timestamp: 2025-07-31T11:17:31.456Z
Learning: sentry/electron package version 6.8.0 is the current latest version available on npm as confirmed by direct npm registry API query. This package version is fully compatible with Sentry core v9.
Applied to files:
apps/server-mcp/package.jsonapps/server-api/package.json
📚 Learning: 2025-09-29T04:47:10.455Z
Learnt from: syns2191
Repo: ever-co/ever-gauzy PR: 9132
File: packages/desktop-activity/src/lib/desktop-queue.ts:1-0
Timestamp: 2025-09-29T04:47:10.455Z
Learning: In the ever-gauzy codebase, TypeScript is configured with "allowSyntheticDefaultImports": true and "esModuleInterop": false. Many packages use "module": "commonjs". With this configuration, namespace imports like "import * as Queue from 'better-queue'" work correctly for CommonJS modules, while default imports would fail. The existing namespace import pattern should be preserved for modules like better-queue and is-online.
Applied to files:
packages/desktop-activity/package.jsonapps/server-api/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.json
📚 Learning: 2025-07-11T01:30:50.701Z
Learnt from: syns2191
Repo: ever-co/ever-gauzy PR: 9033
File: packages/desktop-activity/src/lib/activity-window.ts:113-120
Timestamp: 2025-07-11T01:30:50.701Z
Learning: In the ever-gauzy codebase, the build system compiles all static import statements to require statements. When working with ESM-only modules like 'get-windows', the Function constructor approach with dynamic import is used to bypass build-time transformations, as seen in packages/desktop-activity/src/lib/activity-window.ts.
Applied to files:
packages/desktop-activity/package.jsonpackages/desktop-lib/package.jsonapps/agent/src/main/init/app.tsapps/server-api/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.jsonapps/agent/src/package.json
📚 Learning: 2025-08-02T12:37:43.958Z
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9082
File: apps/desktop/package.json:60-63
Timestamp: 2025-08-02T12:37:43.958Z
Learning: In the ever-co/ever-gauzy project, sentry/core is explicitly declared as a dependency in package.json files (even when it could be pulled transitively) to prevent package version mismatches and ensure consistent Sentry core versions across all applications in the monorepo. This is a deliberate dependency management strategy by samuelmbabhazi to maintain version consistency.
Applied to files:
apps/desktop-timer/src/package.jsonapps/server-api/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.jsonapps/agent/src/package.json
📚 Learning: 2025-08-02T12:37:35.872Z
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9082
File: apps/agent/src/package.json:142-146
Timestamp: 2025-08-02T12:37:35.872Z
Learning: User samuelmbabhazi explicitly adds sentry/core dependencies across package.json files in the ever-co/ever-gauzy monorepo to avoid package version mismatches and ensure consistent version resolution, particularly during major Sentry version migrations. This is their preferred approach for dependency management over relying on workspace hoisting.
Applied to files:
apps/desktop-timer/src/package.jsonapps/server-api/src/package.jsonapps/server-mcp/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.jsonapps/agent/src/package.json
📚 Learning: 2025-08-02T12:37:40.134Z
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9082
File: apps/desktop-timer/src/package.json:147-151
Timestamp: 2025-08-02T12:37:40.134Z
Learning: In the ever-co/ever-gauzy project, user samuelmbabhazi explicitly adds sentry/core as a direct dependency alongside other Sentry packages (like sentry/node, sentry/electron, sentry/profiling-node) to avoid package version mismatches and ensure all Sentry packages use the same core version. This is their deliberate dependency management strategy, especially during major Sentry version migrations.
Applied to files:
apps/desktop-timer/src/package.jsonapps/server-api/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.jsonapps/agent/src/package.json
📚 Learning: 2025-03-28T22:03:25.162Z
Learnt from: syns2191
Repo: ever-co/ever-gauzy PR: 8874
File: apps/agent/src/main/init/app.ts:131-139
Timestamp: 2025-03-28T22:03:25.162Z
Learning: The agent application is designed to prevent closing on all platforms when all windows are closed, not just on macOS. The `event.preventDefault()` is intentionally called unconditionally in the 'window-all-closed' event handler to maintain this behavior.
Applied to files:
apps/agent/src/main/init/app.ts
📚 Learning: 2025-06-16T15:15:03.909Z
Learnt from: syns2191
Repo: ever-co/ever-gauzy PR: 8999
File: apps/agent/src/main/window-manager.ts:175-176
Timestamp: 2025-06-16T15:15:03.909Z
Learning: In the apps/agent/src/main/window-manager.ts file, the preload path returned by getPreloadPath() is validated for existence in another function, so additional fs.existsSync checks are not needed before passing it to window constructors like ScreenCaptureNotification.
Applied to files:
apps/agent/src/main/init/app.ts
📚 Learning: 2025-07-13T02:33:55.890Z
Learnt from: samuelmbabhazi
Repo: ever-co/ever-gauzy PR: 9042
File: packages/contracts/src/lib/employee.model.ts:124-127
Timestamp: 2025-07-13T02:33:55.890Z
Learning: In packages/contracts/src/lib/employee.model.ts, the agent settings flags (allowAgentAppExit, allowLogoutFromAgentApp) and tracking settings flags (trackKeyboardMouseActivity, trackAllDisplays) are intentionally omitted from IEmployeeCreateInput interface. These flags should always take default values when creating employees and can only be modified later through update operations, not during initial creation.
Applied to files:
apps/agent/src/main/init/app.ts
📚 Learning: 2025-06-09T00:20:59.777Z
Learnt from: syns2191
Repo: ever-co/ever-gauzy PR: 8993
File: apps/agent/src/main/init/app.ts:31-32
Timestamp: 2025-06-09T00:20:59.777Z
Learning: In apps/agent/src/main/init/app.ts, the EventHandler initialization during application startup should not have error handling. The user prefers that any failure during EventHandler.getInstance() or eventHandler.mainListener() should cause the application to fail immediately rather than continue with graceful error handling, as this is considered a critical component that must initialize successfully.
Applied to files:
apps/agent/src/main/init/app.ts
📚 Learning: 2025-11-24T18:40:16.628Z
Learnt from: CR
Repo: ever-co/ever-gauzy PR: 0
File: .cursor/rules/angular.mdc:0-0
Timestamp: 2025-11-24T18:40:16.628Z
Learning: Applies to **/*.ts : Keep lifecycle hook methods simple; move logic into well‑named private methods and call them from the hook
Applied to files:
apps/agent/src/main/init/app.ts
📚 Learning: 2025-04-20T09:30:18.913Z
Learnt from: syns2191
Repo: ever-co/ever-gauzy PR: 8909
File: packages/desktop-activity/src/lib/kb-mouse.ts:1-2
Timestamp: 2025-04-20T09:30:18.913Z
Learning: When importing Node.js built-in modules in TypeScript/JavaScript files, use the node: protocol prefix (e.g., `import { EventEmitter } from 'node:events';` instead of `import { EventEmitter } from 'events';`) as it's more explicit and signals that the imported module belongs to Node.js.
Applied to files:
apps/agent/src/main/init/app.ts
📚 Learning: 2025-07-23T16:00:29.020Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9029
File: apps/mcp/tsconfig.json:13-14
Timestamp: 2025-07-23T16:00:29.020Z
Learning: In the ever-co/ever-gauzy project, empty "files" and "include" arrays in TypeScript configuration files (like apps/mcp/tsconfig.json) are written deliberately and should not be flagged as issues. The project intentionally uses this pattern where configurations rely solely on referenced configs via the "references" array.
Applied to files:
apps/server-api/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.json
📚 Learning: 2025-10-19T17:45:01.123Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9153
File: apps/mcp-auth/tsconfig.spec.json:6-6
Timestamp: 2025-10-19T17:45:01.123Z
Learning: In the ever-co/ever-gauzy project, the apps/mcp-auth/tsconfig.spec.json intentionally has moduleResolution set to "node10". This configuration is correct for the mcp-auth app's code structure and should not be changed to "node16" or "nodenext".
Applied to files:
apps/server-mcp/src/package.jsonapps/server/src/package.jsonapps/desktop/src/package.jsonpackage.json
📚 Learning: 2025-10-19T17:44:21.334Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9153
File: apps/mcp-auth/tsconfig.json:2-12
Timestamp: 2025-10-19T17:44:21.334Z
Learning: In the ever-co/ever-gauzy project, the apps/mcp-auth/tsconfig.json intentionally has strict mode and related compiler options (strict, noImplicitOverride, noPropertyAccessFromIndexSignature, noImplicitReturns, noFallthroughCasesInSwitch) set to false. This configuration is correct for the mcp-auth app's code structure and should not be changed to strict mode.
Applied to files:
apps/server-mcp/src/package.jsonpackage.json
📚 Learning: 2025-08-05T20:28:00.875Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9067
File: packages/mcp-server/src/lib/tools/candidates.ts:25-610
Timestamp: 2025-08-05T20:28:00.875Z
Learning: In the ever-co/ever-gauzy packages/mcp-server project, the user RolandM99 prefers to keep tool files consolidated rather than splitting them into smaller modules. Files around 600+ lines are considered maintainable and easy to read when the code is well-structured, like in packages/mcp-server/src/lib/tools/candidates.ts.
Applied to files:
apps/server-mcp/src/package.json
📚 Learning: 2025-07-25T04:53:31.370Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9029
File: packages/mcp-server/src/lib/config/server-info.ts:2-2
Timestamp: 2025-07-25T04:53:31.370Z
Learning: In packages/mcp-server/src/lib/config/server-info.ts, the user RolandM99 confirmed that the server name "Gauzy MCP Server" should remain hardcoded because it will stay the same across all environments (development, staging, production). The user prefers this approach over using environment variables for the server name.
Applied to files:
apps/server-mcp/src/package.jsonpackage.json
📚 Learning: 2025-11-18T16:50:45.887Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9221
File: packages/auth/src/lib/mcp/server/oauth-authorization-server.ts:348-349
Timestamp: 2025-11-18T16:50:45.887Z
Learning: In packages/auth/src/lib/mcp/server/oauth-authorization-server.ts, the CSP configuration intentionally includes "https://cdn.jsdelivr.net" in styleSrc, fontSrc, and connectSrc directives to support MCP Server OAuth integration with a third-party app built in the OpenAI ecosystem. This is a forward-looking requirement for external integration.
Applied to files:
apps/server-mcp/src/package.json
📚 Learning: 2025-11-18T16:17:36.298Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9221
File: packages/auth/src/lib/mcp/utils/config-manager.ts:85-87
Timestamp: 2025-11-18T16:17:36.298Z
Learning: In the ever-co/ever-gauzy project packages/auth/src/lib/mcp/utils/config-manager.ts, when NODE_ENV is set to 'stage', it intentionally maps to 'production' environment settings. This is by design to treat staging environments with production-like configuration.
Applied to files:
apps/server-mcp/src/package.jsonpackage.json
📚 Learning: 2025-10-19T17:13:19.912Z
Learnt from: RolandM99
Repo: ever-co/ever-gauzy PR: 9153
File: apps/mcp-auth/project.json:42-46
Timestamp: 2025-10-19T17:13:19.912Z
Learning: In the ever-co/ever-gauzy project, the apps/mcp-auth/project.json test target configuration with only `passWithNoTests: true` option (without an executor) is correct for the mcp-auth app's code structure and should not be modified.
Applied to files:
package.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: cubic · AI code reviewer
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (21)
apps/server-mcp/package.json (1)
30-30: Verify electron-builder 26.0.3 and electron ^38.1.2 compatibility.Confirm that electron-builder 26.0.3 (pinned) is fully compatible with electron versions in the ^38.1.2 range. The PR notes indicate v26.0.12 was attempted but caused issues—ensure 26.0.3 has no known incompatibilities with Electron 38.x.
Also applies to: 32-32
packages/desktop-ui-lib/package.json (1)
73-73: LGTM: Straightforward Electron version bump for UI library.The Electron upgrade aligns with the monorepo-wide update. As a library with peer dependencies, this ensures Angular compatibility and type definitions are current. No concerns.
.cspell.json (1)
728-728: LGTM: Valid spell-check dictionary addition.STARTTLS is a legitimate SMTP protocol term and properly added to the cspell dictionary. This supports email functionality in the codebase.
packages/desktop-activity/package.json (1)
36-36: Verify desktop-activity native bindings rebuild correctly with Electron 38.1.2.Major dependency upgrades require validation:
- better-sqlite3 (9.6.0 → 12.2.0): Native module rebuild via @electron/rebuild needed for Electron 38.1.2.
- Electron (^30.0.1 → ^38.1.2): Changes native binding compilation target.
- ESM modules (get-windows, is-online): Confirm compatibility with new Electron runtime using existing import patterns.
Ensure local testing included activity capture on Windows/macOS/Linux.
packages/core/package.json (1)
113-113: Better-sqlite3 12.2.0 introduces breaking changes; verify native rebuild configuration in dependent packages.The upgrade from 9.6.0 to 12.2.0 spans two major version bumps (v10.0.0 and v12.0.0). While v12.0.0 dropped support for Electron 26–28 (EOL), Electron 38 remains compatible. However, native bindings require rebuilding for each Electron version. Confirm that all packages depending on better-sqlite3 (including packages/desktop-activity) have proper @electron/rebuild configuration and are tested against Electron 38.
apps/desktop-timer/package.json (1)
27-28: Electron and electron-builder version bumps look good.The update from Electron ^30.0.1 to ^38.1.2 and electron-builder ^24.13.3 to 26.0.3 is consistent with other changes in this PR.
apps/server-api/package.json (1)
27-27: Electron and electron-builder version bumps are consistent with the project-wide upgrade.Updates match the pattern applied across other electron-dependent apps in the PR.
Also applies to: 29-29
packages/desktop-lib/package.json (2)
37-37: Verify better-sqlite3 12.2.0 compatibility with Electron 38.1.2.The bump from 9.6.0 to 12.2.0 is a major version jump. While you reported testing local builds, please confirm:
- Binary compatibility with Electron 38.1.2 across all target platforms (Windows, macOS, Linux)
- No breaking changes to the sqlite API usage in packages/desktop-lib or downstream consumers
- No additional native module compilation issues
The past reviewer flagged potential issues with better-sqlite3 updates causing build problems, so careful validation here is important.
66-66: Electron version update is consistent.The upgrade to ^38.1.2 aligns with the project-wide Electron update across all packages.
apps/server-mcp/src/package.json (1)
118-147: File-based local package resolution is correctly implemented.The use of
file:../../../dist/packages/paths for internal Gauzy packages and the corresponding resolutions block follows the new monorepo pattern established in this PR.Please confirm that
apps/server-mcpis intended to be a Node.js-only application. If so, verify that its TypeScript configuration (e.g.,tsconfig.electron.json) does not include"electron"in the types array, as this can cause build errors in Node-only contexts (per learnings from PR #9068).apps/server-api/src/package.json (2)
188-190: Verify necessity of new runtime dependencies.Three new dependencies are being added:
@as-integrations/express5@^1.1.2call-bind-apply-helpers@^1.0.2cheerio-select@^2.1.0These appear to be transitive dependencies now being explicitly declared. Please clarify:
- Why are these needed as direct dependencies rather than relying on transitive resolution?
- Is
@as-integrations/express5needed for Express 5 compatibility in the new Electron/builder stack?- How are
call-bind-apply-helpersandcheerio-selectused in the codebase?
129-129: Resolutions block correctly implements the new monorepo dependency strategy.The comprehensive resolutions block for all Gauzy internal packages ensures consistent version resolution across the monorepo and aligns with the broader refactor to replace workspace-based hoisting with explicit file-based references.
Also applies to: 192-226
apps/desktop-timer/src/package.json (2)
166-167: New dependencies are consistent with the broader refactor.The addition of
call-bind-apply-helpersandcheerio-selectmirrors the pattern inapps/server-api/src/package.json, suggesting these are transitive dependencies being explicitly declared for version consistency across the monorepo.
169-178: Resolutions block correctly pins internal packages.The comprehensive resolutions block ensures all Gauzy internal packages resolve to their built dist versions, maintaining consistency across the desktop-timer application.
apps/server/src/package.json (2)
188-190: New dependencies are consistent across server apps.The identical three new dependencies (
@as-integrations/express5,call-bind-apply-helpers,cheerio-select) are consistently applied across bothapps/server/src/package.jsonandapps/server-api/src/package.json, indicating a deliberate monorepo-wide strategy.
129-129: Resolutions block maintains consistency and ensures proper dependency resolution.The comprehensive and identical resolutions block across server applications ensures all Gauzy internal packages and their transitive dependencies resolve correctly from the dist/ folder.
Also applies to: 192-226
package.json (2)
104-112: ✓ Build script electronVersion parameters are consistent.All electron build scripts across desktop, desktop-timer, server, api-server, agent, and MCP applications use
-c.electronVersion=38.2.2, ensuring consistent Electron version specification during building.Also applies to: 307-315, 321-329, 346-356, 369-376, 400-410
478-481: ABI resolution configuration is properly aligned with Electron 38.The addition of node-abi resolutions and electron-rebuild overrides ensures consistent ABI (Application Binary Interface) handling across the project's native module compilation. The specified version 3.78.0 correctly corresponds to Electron 38.1.2's ABI requirements.
Also applies to: 516-516, 604-604, 653-654, 663-667
apps/desktop/src/package.json (2)
191-226: Resolutions block effectively pins internal package versions to local dist builds.The new resolutions block is a sound approach for ensuring transitive dependencies of @gauzy/* packages resolve to your local dist outputs, preventing version mismatches in the monorepo. The coverage and consistency look correct—all resolutions entries mirror used dependencies. Based on learnings, this aligns with established patterns in your monorepo for explicit dependency management.
125-125: These are legitimate transitive dependencies of electron-builder 26; no action needed.Both
call-bind-apply-helpers(v1.0.2) andcheerio-select(v2.1.0) are confirmed as legitimate npm packages and verified as transitive dependencies of electron-builder 26. No security vulnerabilities exist in the specified versions. These are not typos or unintended entries.apps/agent/src/package.json (1)
142-151: Resolutions block correctly scoped to this app's actual @gauzy/ dependencies.*The resolutions pattern here mirrors the desktop app's approach—pinning internal packages to local dist builds—but is appropriately scoped to only the packages this agent app uses. This is consistent and correct. Based on learnings, this aligns with your established monorepo dependency management strategy.
| "electron": "^38.1.2", | ||
| "electron-builder": "26.0.3", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
electron-builder 26.0.3 compatibility electron 38
💡 Result:
Short answer: No—electron-builder 26.0.3 predates Electron 38 and does not include later fixes for supporting Electron ≥38. Upgrade electron-builder to a newer 26.x release (changes in releases after 26.0.3 added explicit support / fixes for Electron >38). [1][2]
Sources:
- electron 38 release notes. [1]
- electron-builder releases / changelog showing later fixes for Electron >38 (changes after 26.0.3). [2]
🏁 Script executed:
# Check package.json for context around these versions and any related comments
cd apps/server && cat -n package.json | head -30Repository: ever-co/ever-gauzy
Length of output: 180
🏁 Script executed:
# Search for any documentation or comments about electron-builder pinning strategy
rg "electron-builder" --type json -A 2 -B 2Repository: ever-co/ever-gauzy
Length of output: 180
Upgrade electron-builder to support Electron 38.
electron-builder 26.0.3 predates Electron 38 and lacks support for it. The caret on electron (^38.1.2) allows patches that electron-builder 26.0.3 cannot handle. Upgrade electron-builder to a later 26.x release that includes explicit support and fixes for Electron ≥38.
🤖 Prompt for AI Agents
In apps/server/package.json lines 24-25 the project pins "electron-builder" to
26.0.3 while Electron is ^38.1.2; upgrade electron-builder to a 26.x release
that explicitly supports Electron ≥38 (for example 26.2.0 or the latest 26.x),
update package.json dependency accordingly, run npm/yarn install, and verify the
production build and packaged artifacts to ensure no incompatibility remains.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 21 files
Prompt for AI agents (all 1 issues)
Check if these issues are valid — if so, understand the root cause of each and fix them.
<file name="package.json">
<violation number="1" location="package.json:516">
P2: Electron version mismatch: dependency specifies `^38.1.2` but build scripts use `electronVersion=38.2.2`. These should be aligned to avoid potential build inconsistencies. Consider updating the dependency to `^38.2.2` to match the build configuration.</violation>
</file>
Reply to cubic to teach it or ask questions. Re-run a review with @cubic-dev-ai review this PR
| "camelcase": "^6.3.0", | ||
| "dotenv": "^16.0.3", | ||
| "electron": "^30.0.1", | ||
| "electron": "^38.1.2", |
There was a problem hiding this comment.
P2: Electron version mismatch: dependency specifies ^38.1.2 but build scripts use electronVersion=38.2.2. These should be aligned to avoid potential build inconsistencies. Consider updating the dependency to ^38.2.2 to match the build configuration.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At package.json, line 516:
<comment>Electron version mismatch: dependency specifies `^38.1.2` but build scripts use `electronVersion=38.2.2`. These should be aligned to avoid potential build inconsistencies. Consider updating the dependency to `^38.2.2` to match the build configuration.</comment>
<file context>
@@ -511,7 +513,7 @@
"camelcase": "^6.3.0",
"dotenv": "^16.0.3",
- "electron": "^30.0.1",
+ "electron": "^38.1.2",
"jsdom": "^23.0.1",
"lodash-es": "^4.17.21",
</file context>
PR
Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.