chore: pin package-lock.json to LF and normalise the one CRLF lockfile - #815
Closed
github-actions[bot] wants to merge 1 commit into
Closed
chore: pin package-lock.json to LF and normalise the one CRLF lockfile#815github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
fuzefront-website/backend/package-lock.json is the only lockfile in the
repo stored with CRLF. It predates gate-line-endings, so it sat unnoticed
until a PR touched it — same story as the CLAUDE.md / authentikPassword.ts
entries already pinned at the bottom of .gitattributes.
The existing globs do not cover it:
package.json text eol=lf
**/package.json text eol=lf
neither matches package-lock.json, so the lockfile was never pinned.
This matters more for a lockfile than for an ordinary source file. npm
rewrites the whole file on every resolution, so a CRLF-stored lockfile
regenerated on Linux comes back entirely LF: a 9-entry dependency change
renders as a 7,124-line diff. That hides the real change from review and
trips gate-line-endings at the same time.
Content is byte-identical modulo line endings — verified by stripping \r
from both sides and diffing (no difference). Split out of the #747
dependency work so the deps PR keeps a reviewable diff.
Refs #747
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013tMciHkPE8To7V67CsgKKc
7 tasks
izzywdev
added a commit
that referenced
this pull request
Aug 27, 2026
The stranded-branch detector's create path went live when can_approve_pull_request_reviews was flipped to true on 2026-08-23, and started opening PRs. Those PRs could not merge. GitHub does not trigger workflow runs from events raised by GITHUB_TOKEN, so a PR opened with it gets no pull_request runs at all — no gates, no auto-merge job. This workflow also applies the auto-merge label, so the result is a PR that looks handled and is blocked forever on checks that will never start. Observed on #815, #817, #818 and again on #821-#830, each sitting at exactly one check until closed and reopened by hand, at which point 40+ checks appeared immediately. Fixes: - Create the PR with GH_RELEASE_PAT (an ordinary user event, which does trigger CI), falling back to GITHUB_TOKEN so an unset secret degrades rather than breaks the job. - If the fallback is taken, fail loudly with the PR number, the close/reopen command that unsticks it, and the secret to set. Creating a PR that cannot merge is not a success. The header claimed this workflow "CANNOT open a pull request on this repo, and never has" — true until 2026-08-23, and the reason nobody noticed: it told readers the workflow did nothing while it was opening unmergeable PRs. Corrected in place, with the original tradeoff kept as a historical note.
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.
Duplicate of #816 — same branch (
claude/normalise-lockfile-eol), same commit. Theopen-prautomation and an explicitcreate_pull_requestcall raced and both opened a PR for this branch. Closing this one; #816 carries the full description and is the one being tracked.