feat!: bump @electron/windows-sign to 2.1.0 - #615
Merged
Merged
Conversation
@electron/windows-sign 2.1.0 ships a signtool.exe that supports Azure Trusted Signing (/dlib), so windowsSign users no longer need to point signToolPath at a Windows SDK copy. - windows-sign 2.x is ESM-only and requires Node.js 22.12+. It stays an optional dependency, and the error and spec gate now name 22.12. - Compile with module "node16" (TypeScript 5.4) so the dynamic import stays a real import() and the package's exports-only types resolve. - Add Node.js 22.12 to CI so the signing spec runs, and install with --ignore-engines on older versions so the types are present to build.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
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. Ignoring alerts on:
|
…ency @electron/windows-sign 2.x requires Node.js 22.12 or later. It was only an optional dependency so that older Node.js versions could still install this package, so it is now a regular dependency and is loaded without a fallback. CI now tests Node.js 22.12 and 24. BREAKING CHANGE: Requires Node.js 22.12 or later. windowsSign inherits @electron/windows-sign 2.x behavior: hook modules are loaded with import(), so TypeScript `export default` hooks compiled to CommonJS and extensionless hookModulePath values no longer resolve, and errors thrown by a hook now fail signing. The published type declarations need TypeScript 5.3 or later.
felixrieseberg
changed the title
Member
Author
|
@SocketSecurity ignore npm/@electron/windows-sign@2.1.0 |
dsanders11
reviewed
Sep 10, 2026
dsanders11
left a comment
dsanders11
left a comment
Member
There was a problem hiding this comment.
If we're doing the v6.0.0 bump, I think we should:
- Do the ESM conversion to align with the rest of our Ecosystem WG packages
- Finally promote this package to
@electron/windows-installersince it's the only package still not in the@electron/*namespace
dsanders11
approved these changes
Sep 10, 2026
dsanders11
left a comment
dsanders11
left a comment
Member
There was a problem hiding this comment.
Merging this with the release workflow disabled so we can batch a few other breaking changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bumps
@electron/windows-signto 2.1.0. Since electron/windows-sign#123, its vendoredsigntool.exesupports Azure Trusted Signing (/dlib), sowindowsSignusers no longer need to pointsignToolPathat a Windows SDK copy (as electron/fiddle#2004 does today).windows-sign 2.x is ESM-only and requires Node.js 22.12+, so this is a major release:
enginesis now>=22.12.0, and windows-sign becomes a regular dependency. It was only optional to spare older Node.js versions, so the fallback loader andsemvergo away.module: "node16"on TypeScript 5.4, so windows-sign's exports-only types resolve andimport()stays a real dynamic import.Breaking changes
.d.tsfiles need TypeScript 5.3+ (they use theresolution-modeimport attribute).import(), so TypeScriptexport defaulthooks compiled to CommonJS and extensionlesshookModulePathvalues no longer resolve. Errors thrown by a hook now fail signing instead of being logged.signWithParamsstring are now stripped.Please keep the
BREAKING CHANGEfooter when squash-merging so semantic-release cuts 6.0.0.Test plan
On Linux with Node.js 22:
yarn buildandyarn lintpass, andlib/sign.jsemitsimport('@electron/windows-sign'). The platform-independent specs pass; the Windows signing spec only runs in CI. The hook-loading difference was reproduced with a Node 22 script comparingrequire()andimport().