fix(pnpmfile): strip usocket from dbus-next.dependencies too#2363
Merged
Conversation
dbus-next@0.10.2 lists usocket in both `dependencies` and `optionalDependencies`. The existing hook only stripped it from optionalDependencies, so any fresh pnpm resolution (e.g. dependabot regenerating the lockfile when bumping an unrelated package) picked usocket back up via dependencies, breaking the Install step on Windows with: uwrap.cc(2,10): error C1083: Cannot open include file: 'sys/ioctl.h' Also strip from dependencies so the resolution stays clean across pnpm versions and fresh installs. dbus-next degrades gracefully to Node's built-in net module without usocket. Lockfile diff is just the pnpmfile checksum — the resolution graph itself was already usocket-free on main. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Hardens the existing pnpm readPackage hook so that usocket is stripped from dbus-next's regular dependencies in addition to optionalDependencies, preventing Windows install failures when the lockfile is regenerated.
Changes:
- Extend the
dbus-nexthook ints/.pnpmfile.cjsto deleteusocketfrom bothdependenciesandoptionalDependencies. - Update the explanatory comment to document the dual-listing in dbus-next@0.10.2 and the Windows failure mode.
- Refresh
pnpmfileChecksumints/pnpm-lock.yamlto reflect the new hook contents.
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| ts/.pnpmfile.cjs | Strip usocket from both dependencies and optionalDependencies of dbus-next; updated comment. |
| ts/pnpm-lock.yaml | Updated pnpmfile checksum after hook change. |
Files not reviewed (1)
- ts/pnpm-lock.yaml: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
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
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.
Problem
Recent dependabot PRs (#2360, #2361) and the daily dependabot remediation workflow have been failing the
Install dependenciesstep on Windows with:This is
usocket@0.3.0(a native Unix-domain-socket module) trying to compile vianode-gyp. POSIX-only headers ⇒ Windows build fails.Root cause
dbus-next@0.10.2''s package.json listsusocketin both:The existing hook in
ts/.pnpmfile.cjsonly stripped fromoptionalDependencies.main''s lockfile happens to be usocket-free, but any fresh resolution (e.g. dependabot regeneratingpnpm-lock.yamlwhen bumping an unrelated package) picks usocket back up via the regulardependenciesentry and Windows installs fail.Fix
Strip usocket from both
dependenciesandoptionalDependenciesin thereadPackagehook. dbus-next degrades gracefully to Node''s built-innetmodule without it (see comment in the hook).Verification
pnpm install --lockfile-onlyafter the change — lock diff is only the pnpmfileChecksum, no actual graph changes (resolution was already usocket-free on main; this change just hardens it against future re-resolutions).fix-dependabot-alertsworkflow should now pass WindowsInstall dependencies.