process.mas read-only property
process.mas is a read-only boolean that is true for Mac App Store builds, and undefined for other builds.
Electron · Tutorial · all subjects
code signing & distribution
24 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
process.windowsStore read-only property
process.windowsStore is a read-only boolean that is true if the app is running as an MSIX package (including AppX for Windows Store), otherwise it is undefined.
Chromium upgrade Phase One success criteria
Phase One is complete when: `e sync --3` exits with code 0 (no patch failures), and all changes are committed per commit guidelines. Linter requirements: for code/patch edits, the title must be exactly `{CL-Number}: {upstream CL original title}` with `Ref: {URL}` in the body. For metadata-only patch updates (hashes/line numbers), the message must be exactly `chore: update patches` with no body.
Never delete patches without certainty they are not needed
Do not delete or skip patches unless 100% certain the patch is no longer needed. Complicated conflicts or hard to resolve issues should be presented to the user after exhausting all other options. Never delete a patch just because you cannot solve it.
Never skip patches and manually recreate with new commit
Never use `git am --skip` and then manually recreate a patch by making a new commit. This destroys the original patch's authorship, commit message, and position in the series. If `git am --continue` reports 'No changes', investigate why — the changes were likely absorbed by a prior conflict resolution's 3-way merge. Present this situation to the user rather than skipping and recreating.
Clear rerere cache before starting Chromium upgrade
Run `git rerere clear` in both the electron and chromium repos at the start of each upgrade session. Stale recorded resolutions from a prior attempt can silently apply wrong merges.
Ensure pre-commit hooks are installed before Chromium upgrade
Check that `.git/hooks/pre-commit` exists before starting. If not, run `yarn husky` to install it. The hook runs `lint-staged` which handles clang-format for C++ files.
Export patches after git am --continue succeeds
Once `git am --continue` succeeds, you MUST run `e patches {target}` to export fixes before returning to running `e sync --3` again.
Commit build/siso_revision separately during Chromium upgrade
If the sync changed `build/siso_revision` (the `gen_siso_revision` hook rewrites it when the new Chromium pins a different siso), commit that file on its own as `chore: update siso revision`. CI builds siso from this file and gn-check fails the roll if it is stale.
Chromium upgrade Phase One command sequence
Phase One workflow: (1) Run `e sync --3` with the `--3` flag to enable 3-way merge; (2) if it fails, identify target repo and patch from error output, analyze failure, fix conflict in target repo's working directory, run `git am --continue`, and export fixes with `e patches {target}`, then repeat from step 1; (3) when `e sync --3` succeeds, run `e patches all` to export all patches; (4) handle `build/siso_revision` if changed; (5) commit changes following phase-one-commit-guidelines.
Preserve patch authorship during conflict fixes
Keep original author in TODO comments (from patch `From:` field) when fixing patches. Never change TODO assignees — `TODO(name)` must retain original name.
Update patch descriptions when upstream changes
If upstream changed (e.g., `DCHECK` → `CHECK_IS_TEST`), update patch commit message to reflect current state.
Chromium upgrade Phase Two success criteria
Phase Two is complete when: `e build -k 999 -- --quiet` exits with code 0 (no build failures), `e start --version` has been run to check Electron launches, and all changes are committed per commit guidelines. Linter requirements: for code/patch edits, title must be exactly `{CL-Number}: {upstream CL original title}` with `Ref: {URL}` in body. For metadata-only patch updates, message must be exactly `chore: update patches` with no body.
Do not modify Chromium code to fix build issues
Never comment out code or delete features to fix build issues. Strongly avoid making changes to the code in chromium to fix Electron's build. Update Electron's code to account for changes in Chromium APIs instead. Make all existing code, logic, and intention work.
Chromium upgrade Phase Two command sequence
Phase Two workflow: (1) Run `e build -k 999 -- --quiet` to build Electron with continued-on-errors; (2) if it fails, identify the failing file from error output, fix the build issue by adapting Electron's code, run `e build -t {target_that_failed}.o` to build just that target, commit changes following phase-two-commit-guidelines, and repeat; (3) after any commit, run `git status` in electron repo and commit dependent `.patch` files with `git commit -am 'chore: update patches'`; (4) when build succeeds, run `e start --version` to validate Electron launches; (5) check for pending changes in Chromium repo and follow patch fix instructions if needed; (6) verify final commits referencing each upstream CL exactly once and consolidate duplicates if found.
Identify failed build target from error output
Extract the target name from the failure line in build log. For example, from `FAILED: 2e506007-8d5d-4f38-bdd1-b5cd77999a77 "./obj/electron/chromium_src/chrome/process_singleton_posix.o" CXX obj/electron/chromium_src/chrome/process_singleton_posix.o`, the target name is `obj/electron/chromium_src/chrome/process_singleton_posix.o`.
Build single target to verify Chromium upgrade fix
Run `e build -t {target}.o` to build just one specific target to verify a fix after making changes during Phase Two.
Patch fixing workflow in Chromium upgrade
For files that Electron patches (check with `grep -l "filename" patches/chromium/*.patch`): (1) Edit the file in Chromium source tree; (2) Create a fixup commit targeting the original patch commit; (3) Run `git add <modified-file>` and `git commit --fixup=<original-patch-commit-hash>`; (4) Run `GIT_SEQUENCE_EDITOR=: git rebase --autosquash --autostash -i <commit>^` to rebase; (5) Export updated patch with `e patches chromium`; (6) Commit the updated patch file following phase-one-commit-guidelines.
Find original patch commit for fixup during upgrade
To find the original patch commit to fixup, run `git log --oneline | grep -i "keyword from patch name"`. The base commit for rebase is the Chromium commit before patches were applied, found by checking the `refs/patches/upstream-head` ref.
Electron code fixes during Phase Two do not need patch export
When the build error is in Electron's own source code (files in shell/, electron/, etc.), edit files directly in the electron repo and commit directly — no patch export is needed.
Verify upstream CL references in final commits
Run `git log --format='%h %B'` over commits this upgrade added (everything since the `chore: bump chromium in DEPS` commit) and verify that each upstream CL is referenced by exactly one non-fixup commit. Check full messages, not just titles, since `Ref:` lines live in commit bodies. If a CL appears in more than one non-fixup commit, consolidate with `git commit --fixup` plus autosquash rebase per phase-two-commit-guidelines.
e sync command syntax and options
`e sync --3` runs clone deps and applies patches with 3-way merge. The `--3` flag is always required to enable 3-way merge during Chromium upgrades.
e patches command syntax and variations
`e patches {target}` exports commits from target repo to patch files. `e patches all` exports all patches from all targets. `e patches {target} --commit-updates` exports patches and auto-commits trivial changes. `e patches --list-targets` lists targets and config paths.
When to edit patches directly vs during conflict resolution
During active `git am` conflict, fix in target repo then run `git am --continue`. When modifying patch outside conflict, edit the `.patch` file directly. When creating new patch (rare, avoid), commit in target repo then run `e patches {target}`. Fix existing patches 99% of the time rather than creating new ones.