Drop a node_modules symlink committed in #30 - #31
Merged
Conversation
Mine, in #30. I symlink `web/node_modules` at a sibling checkout so a fresh worktree can typecheck without a second install, and on the last commit of that PR I did not remove it before `git add -A`. It went in as a mode 120000 blob pointing at `../../../ff3e-app/web/node_modules` — a path that exists on exactly one machine — so a fresh clone gets a dangling symlink that escapes the repo root. CI did not catch it: the Pages build runs its own install over the top and deployed fine. Both .gitignore files said `node_modules/`. The trailing slash means "a directory of that name", and a symlink is not a directory, so nothing matched it. Dropping the slash matches both — which is why this could happen at all, and why it now cannot: with the fix in place, re-creating the same symlink leaves `git status` clean.
42piratas
added a commit
that referenced
this pull request
Aug 3, 2026
The other half of #31, which I said was in that PR and was not: I edited both .gitignore files but only `git rm` had staged anything, so the commit carried the deleted symlink and neither ignore change. The symlink is gone from main; the rule that would have stopped it going in was never committed. `node_modules/` with a trailing slash means "a directory of that name". A symlink is not a directory, which is why nothing matched the one I committed in #30. Without the slash it matches both. Verified on this branch, not on an unstaged working tree: with the change staged, re-creating the same symlink leaves `git status` clean and `git check-ignore -v web/node_modules` reports `web/.gitignore:3`.
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
1 participant
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.
What happened
Mine, in #30. I symlink
web/node_modulesat a sibling checkout so a fresh worktree can typecheck without a secondnpm install, and on the last commit of that PR I did not remove it beforegit add -A.It landed on
mainas a mode120000blob pointing at../../../ff3e-app/web/node_modules— a path that exists on exactly one machine. A fresh clone gets a dangling symlink that escapes the repo root.CI did not catch it. The Pages build runs its own install over the top, so
0af8f7cdeployed fine and the live demo is correct.Why the ignore rule missed it
Both
.gitignorefiles saidnode_modules/. The trailing slash means a directory of that name — a symlink is not a directory, so nothing matched. Dropping the slash matches both.Verified: with the fix applied, re-creating the exact same symlink leaves
git statusclean andgit check-ignore -v web/node_modulesreportsweb/.gitignore:3:node_modules.Checks
tsc --noEmitclean ·npm run buildclean. No source change — one deleted symlink and one character off each ignore file.