Feature Request: Support setting Windows executable metadata (during or after build)

[chroberino]

I’d like to request support for setting Windows executable metadata (e.g. ProductVersion, FileVersion, CompanyName, etc.) either:

• during the pkg build process (preferred)
• or safely after build, e.g. using tools like rcedit, without breaking the generated binary

❌ Current Issue

When using rcedit to modify the .exe after building with pkg, the binary becomes corrupted and fails to run with:

Pkg: Error reading from file.

This seems to be caused by how pkg structures its executables, making post-build modifications unsafe. Unfortunately, this blocks all standard methods of adding or correcting metadata.

Related Issues in the original vercel/pkg

• How to modify properties of the .exe vercel/pkg#212
• Windows: can't edit EXE's resources with tools like rcedit vercel/pkg#149
• RFC: pkg 6.0 vercel/pkg#1655
• Windows binary ICO replacement fails vercel/pkg#812
• Executable File Icon vercel/pkg#318

✅ Suggested Solutions

Ideal (during build)

Add a field in package.json or a CLI flag to set version metadata during the build process. For example:

"pkg": {
  "versionMetadata": {
    "ProductVersion": "6.5.0",
    "FileVersion": "6.5.0",
    "CompanyName": "my-company",
    "ProductName": "my-product"
  }
}

Alternative (after build)

Make the generated .exe compatible with post-build tools like rcedit, postject, etc. so users can safely inject version metadata after building.

📌 Why It Matters

Version metadata is essential for

• displaying correct information in Windows Explorer
• deployment and patching tools
• digital code signing
• QA/version tracking across systems

[robertsLando]

PR?

[chroberino]

@robertsLando, I'm open to submitting a PR, but I'm not yet familiar with the internals of pkg, so I’d appreciate any hints on why post-processing (e.g. with rcedit) breaks the generated executable. Is this an intentional safeguard (e.g. checksum or embedded metadata validation), or just a side effect of how the binary is structured?

Understanding this would help me evaluate whether a proper fix should happen during the build or if there’s a robust way to allow safe postprocessing. Any pointers to relevant parts of the codebase would be greatly appreciated!

[robertsLando]

so I’d appreciate any hints on why post-processing (e.g. with rcedit) breaks the generated executable. Is this an intentional safeguard (e.g. checksum or embedded metadata validation), or just a side effect of how the binary is structured?

Sincerly I have no clue, I know nodejs added some stricter checks starting from newer versions see #87

@faulpeltz may have some hints about that

[faulpeltz]

@chroberino in what way is the exe broken when you edit the resources
does rcedit not like the binary or does it no longer run afterwards?
did this happen with older node/pkg versions or just with 22.x ?
did you try SEA mode (might be a viable option if your source can be included)

you could also try a tool like Exe-Spy or PE-bear to try and find out whats wrong with the file

[chroberino]

@faulpeltz, the generated executable runs fine until rcedit is applied. After applying rcedit, attempting to run the binary results in: Pkg: Error reading from file.

I have now seen this error originates from the pkg-fetch patches applied to Node.js (e.g. node.v20.19.4.cpp.patch):
https://github.com/yao-pkg/pkg-fetch/blob/d231c84ae619ddaaa49b65b6f62fe5f25fda192b/patches/node.v20.19.4.cpp.patch#L245

I assume these patches are implementing the logic that reads an embedded blob from the executable. It appears that rcedit modifies the binary in a way that breaks the loader's ability to locate or interpret the embedded payload, likely by altering offsets, alignment, or headers that the loader depends on.

So, it’s not that rcedit fails during application. Rather, the patched Node runtime fails at startup due to unexpected binary structure changes.

[chroberino]

did this happen with older node/pkg versions or just with 22.x ?

It happens with every node version.

did you try SEA mode (might be a viable option if your source can be included)

I'll give it a try, but I'll miss the compression option of pkg.

you could also try a tool like Exe-Spy or PE-bear to try and find out whats wrong with the file

I'll give these options a try, but according to my assumption ("unexpected binary structure changes") I am afraid this won't help.