My routine npm update, triggered by a GitHub security advisory, runs into the cryptic “Exit handler never called!” error. Alongside a refresher on what package-lock.json and npm update do, my fix is to confirm the lock file is at fault using npm install –no-package-lock, then delete it and regenerate it with a fresh npm install, followed by retesting and rebuilding any artifacts...
How I use docker logs to find the error when a container exits immediately after starting with no visible message. My walkthrough uses a Filebrowser container that crashed on startup due to a newline character in its JSON config, a typo introduced by the blog post I followed instead of the official instructions...
My attempt to rsync a NAS movies directory to an NTFS-formatted USB drive fails with “Operation not permitted” errors on setting times and creating temporary files, even though a manual cp by the same user succeeds. Running rsync with sudo makes the copies work, though owner and permission attributes still get rewritten on every run, possibly because of the NTFS format. I consider the sudo workaround unsatisfactory given my plans to eventually automate the backup...
While trying to clear an npm audit vulnerability in my React app’s nth-check dependency, I investigate confusing version mismatches between package-lock.json and npm list, and find that hand-editing the lock file doesn’t survive an install. A GitHub issue on create-react-app explains the flag is effectively a false positive for a dev-only dependency and can be safely ignored, with a workaround for CI builds. My takeaways include a clearer understanding of package.json versus package-lock.json and the value of searching for the exact error first...
A debugging story about a SwiftUI master/detail list where every row displays the first record’s data. While preparing to replicate my app in Core Data, I work through Swift’s value-type semantics, a Playground experiment, and print debugging before finding the real cause: mutating and reusing a single struct created duplicate UUIDs that broke ForEach, despite a console warning early on...
A debugging session I had while adding Core Data to the FriendFace app: build errors from re-declared NSManagedObject classes turned out to be caused by CodeGen left enabled on one of two entities, and a later class-not-found error came from stale generated files Xcode had left in its build folders. I walk through both issues and end with a note that switching CodeGen to Manual doesn’t delete files Xcode already generated there...
After converting a SwiftUI subview from a function to a struct, list items in my habit list app stopped updating correctly. Suspecting a value versus reference type issue, I distilled the problem into a minimal ObservableObject example, only to find that both the example and the original app now worked. The post walks through the code and the debugging process but ends without an explanation of what caused or fixed the bug...
I compare my iExpense SwiftUI challenge solutions against Paul Hudson’s, covering preferred-currency formatting, styling expense amounts by value, and splitting the list into personal and business sections. After investigating why my ForEach-based split deletes the correct item despite warnings about offset mismatches, I find that SwiftUI’s onDelete already passes correct array indexes and conclude that my approach beats Paul’s filtered-array solution...
