morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #7050] [Bug] npm ci fails on Windows: release-please patch step passes a backslash path to git apply --directory #4260

New issue

Closed

opened 2026-10-31 00:48:11 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:48:11 +00:00

Owner

Originally created by @bhowiebkr on GitHub (Oct 25, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7050

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

On Windows, npm ci in a source checkout fails in the prepare script. applyReleasePleasePatch in scripts/lib/release-proposal.mjs passes relative(project, directory) to git apply --directory. On Windows that is node_modules\release-please, and git rejects the path:

error: invalid path 'node_modules\release-please/build/src/github.js'

git exits 128, so check() rethrows instead of returning false, and prepare stops before husky is installed.

Reproduction

Windows, clean checkout of main at d24ad4f: run npm ci.

With dependencies already installed, the step alone:

node -e "import('./scripts/lib/release-proposal.mjs').then(m => m.applyReleasePleasePatch())"

Expected behavior

The patch is applied, or detected as already applied, as on Linux and macOS.

Impact and scope

With git's default core.protectNTFS, npm ci from source on Windows fails at prepare. It fails every time here. Other git versions and Windows setups were not tested.

REA version

6.7.0 (main at d24ad4f)

Runtime and platform

Windows 11 Pro 10.0.26200, Node 24.22.1, npm 11.19.1, Git 2.47.0.windows.2 (core.protectNTFS at its default, true)

Target and artifact context

None; this is the source install.

Interface

Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

The same step succeeds when only git's NTFS path check is turned off, so the separator is the only problem:

GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=core.protectNTFS GIT_CONFIG_VALUE_0=false node -e "import('./scripts/lib/release-proposal.mjs').then(m => m.applyReleasePleasePatch())"

Applying the patch by hand with --directory 'node_modules\release-please' and that setting gives the same file contents as the patched release-please.

Analysis or suspected cause

relative() uses the platform separator, but git expects / in patch paths. A likely fix is relative(project, directory).split(sep).join("/"), with sep imported from node:path. A local edit that converted the path to forward slashes let npm ci finish here. It was reverted and is not submitted as a PR.

Additional context

Workaround until a fix: set the three GIT_CONFIG_* variables above for npm ci.

Originally created by @bhowiebkr on GitHub (Oct 25, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7050 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior On Windows, `npm ci` in a source checkout fails in the `prepare` script. `applyReleasePleasePatch` in `scripts/lib/release-proposal.mjs` passes `relative(project, directory)` to `git apply --directory`. On Windows that is `node_modules\release-please`, and git rejects the path: ``` error: invalid path 'node_modules\release-please/build/src/github.js' ``` git exits 128, so `check()` rethrows instead of returning `false`, and `prepare` stops before husky is installed. ### Reproduction Windows, clean checkout of `main` at d24ad4f: run `npm ci`. With dependencies already installed, the step alone: ``` node -e "import('./scripts/lib/release-proposal.mjs').then(m => m.applyReleasePleasePatch())" ``` ### Expected behavior The patch is applied, or detected as already applied, as on Linux and macOS. ### Impact and scope With git's default `core.protectNTFS`, `npm ci` from source on Windows fails at `prepare`. It fails every time here. Other git versions and Windows setups were not tested. ### REA version 6.7.0 (`main` at d24ad4f) ### Runtime and platform Windows 11 Pro 10.0.26200, Node 24.22.1, npm 11.19.1, Git 2.47.0.windows.2 (`core.protectNTFS` at its default, true) ### Target and artifact context None; this is the source install. ### Interface Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence The same step succeeds when only git's NTFS path check is turned off, so the separator is the only problem: ``` GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=core.protectNTFS GIT_CONFIG_VALUE_0=false node -e "import('./scripts/lib/release-proposal.mjs').then(m => m.applyReleasePleasePatch())" ``` Applying the patch by hand with `--directory 'node_modules\release-please'` and that setting gives the same file contents as the patched release-please. ### Analysis or suspected cause `relative()` uses the platform separator, but git expects `/` in patch paths. A likely fix is `relative(project, directory).split(sep).join("/")`, with `sep` imported from `node:path`. A local edit that converted the path to forward slashes let `npm ci` finish here. It was reverted and is not submitted as a PR. ### Additional context Workaround until a fix: set the three `GIT_CONFIG_*` variables above for `npm ci`.

bsakaguchi closed this issue

2026-10-31 00:48:11 +00:00

bsakaguchi commented

2026-10-31 00:48:12 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 25, 2026):

Nice, the fix landed quickly — PR #7055 (normalize release dependency patch directory for git apply) directly addresses the root cause described here. The forward-slash normalization in the patch directory matches the proposed workaround, so Windows source installs should be unblocked. Thanks for the fast turnaround!

@XinwangTao commented on GitHub (Oct 25, 2026): Nice, the fix landed quickly — PR #7055 (normalize release dependency patch directory for git apply) directly addresses the root cause described here. The forward-slash normalization in the patch directory matches the proposed workaround, so Windows source installs should be unblocked. Thanks for the fast turnaround!

bsakaguchi commented

2026-10-31 00:48:12 +00:00

Author

Owner

@morluto commented on GitHub (Oct 25, 2026):

Fixed on main by github.com/morluto/rea@c8269ca497. The Git patch argument now normalizes native directory separators to forward slashes without disabling core.protectNTFS. The same commit adds fresh/already-applied/invalid patch regressions and selects the test in Windows CI.

@morluto commented on GitHub (Oct 25, 2026): Fixed on main by https://github.com/morluto/rea/commit/c8269ca49722859de040c1263b43e95d631dc363. The Git patch argument now normalizes native directory separators to forward slashes without disabling core.protectNTFS. The same commit adds fresh/already-applied/invalid patch regressions and selects the test in Windows CI.

bsakaguchi referenced this issue

2026-10-31 01:12:16 +00:00

[PR #4274] [MERGED] fix(lifecycle): preserve observations and cleanup ownership #6153

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#4260

No description provided.

Rows
Columns