Skip to content

fix: importing from electron/utility in ESM #47998

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Aug 9, 2025
Merged

fix: importing from electron/utility in ESM #47998

merged 1 commit into from
Aug 9, 2025

Conversation

dsanders11
Copy link
Member

Description of Change

Follow-up to #47968. I missed that there's a patch to handle the electron/* module imports in ESM mode, as I'd only tested CJS. Our test coverage was a bit sparse so I expanded it to cover both ESM and CJS code paths for the utility process and added additional ESM coverage for these imports across the board.

Checklist

Release Notes

Notes: Fixed an issue where importing from electron/utility in an ESM file threw an error at runtime

@dsanders11 dsanders11 added semver/minor backwards-compatible functionality target/36-x-y PR should also be added to the "36-x-y" branch. target/37-x-y PR should also be added to the "37-x-y" branch. target/38-x-y PR should also be added to the "38-x-y" branch. labels Aug 8, 2025
@electron-cation electron-cation bot added the new-pr 🌱 PR opened recently label Aug 8, 2025
@dsanders11 dsanders11 marked this pull request as ready for review August 8, 2025 06:55
@dsanders11 dsanders11 requested a review from a team as a code owner August 8, 2025 06:55
reitowo
reitowo approved these changes Aug 8, 2025
View reviewed changes
Copy link
Member

@reitowo reitowo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API LGTM

@reitowo
Copy link
Member

reitowo commented Aug 8, 2025

Is it possible to put these sparse definitions of module names in one file?

deepak1556
deepak1556 reviewed Aug 8, 2025
View reviewed changes
Copy link
Member

@deepak1556 deepak1556 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems incorrect that allowing electron/main and electron/renderer in the utility process. These namespaces are for type level separation only and the actual available module list is controlled elsewhere. However it would be nice to make the behavior at type level match what we mention as allowed in the docs.

Not a blocker for this PR, would be a nice follow-up.

@dsanders11 dsanders11 added semver/patch backwards-compatible bug fixes and removed semver/minor backwards-compatible functionality api-review/requested 🗳 labels Aug 8, 2025
@dsanders11
Copy link
Member Author

dsanders11 commented Aug 8, 2025 •
edited
Loading

@deepak1556, agreed on it being something for a follow-up rather than this PR. This behavior is consistent with this comment in the code, so if we want to revisit this behavior we should be sure to update the comment:

electron/lib/common/init.ts

Lines 104 to 109 in 51add3e

// 'electron/{common,main,renderer,utility}' are module aliases
// of the 'electron' module for TypeScript purposes, i.e., the types for
// 'electron/main' consist of only main process modules, etc. It is intentional
// that these can be `require()`-ed from both the main process as well as the
// renderer process regardless of the names, they're superficial for TypeScript
// only.

@electron-cation electron-cation bot removed the new-pr 🌱 PR opened recently label Aug 9, 2025
@codebytere codebytere merged commit d6c0691 into main Aug 9, 2025
73 checks passed
@release-clerk
Copy link

release-clerk bot commented Aug 9, 2025

Release Notes Persisted

Fixed an issue where importing from electron/utility in an ESM file threw an error at runtime

@codebytere codebytere deleted the fix/esm-electron-utility branch August 9, 2025 07:47
This was referenced Aug 9, 2025
Merged
Open
@trop
Copy link
Contributor

trop bot commented Aug 9, 2025

I have automatically backported this PR to "38-x-y", please check out #48019

@trop trop bot added the in-flight/38-x-y label Aug 9, 2025
@trop trop bot mentioned this pull request Aug 9, 2025
Merged
@trop trop bot removed the target/38-x-y PR should also be added to the "38-x-y" branch. label Aug 9, 2025
@trop
Copy link
Contributor

trop bot commented Aug 9, 2025

I have automatically backported this PR to "36-x-y", please check out #48020

@trop
Copy link
Contributor

trop bot commented Aug 9, 2025

I have automatically backported this PR to "37-x-y", please check out #48021

@trop trop bot added in-flight/36-x-y in-flight/37-x-y merged/38-x-y PR was merged to the "38-x-y" branch. merged/37-x-y PR was merged to the "37-x-y" branch. and removed target/36-x-y PR should also be added to the "36-x-y" branch. target/37-x-y PR should also be added to the "37-x-y" branch. in-flight/38-x-y in-flight/37-x-y labels Aug 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@deepak1556 deepak1556 deepak1556 left review comments

@codebytere codebytere codebytere approved these changes

@reitowo reitowo reitowo approved these changes

@VerteDinde VerteDinde Awaiting requested review from VerteDinde

Assignees
No one assigned
Labels
in-flight/36-x-y merged/37-x-y PR was merged to the "37-x-y" branch. merged/38-x-y PR was merged to the "38-x-y" branch. semver/patch backwards-compatible bug fixes
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@dsanders11 @reitowo @deepak1556 @codebytere