Search for a command to run...
Software developer documenting my journey through web and mobile development. I share what I learn, build, and struggle with—from React to SwiftUI, architecture decisions to deployment challenges. Not an expert, just passionate about coding and learning in public. Join me as I navigate the tech landscape one commit at a time.
No comments yet. Be the first to comment.
Daily code discoveries from my developer journey. Each post delivers concise, actionable insights I've uncovered while building with React, Typescript, and more. Brief but impactful lessons for curious developers looking to grow incrementally.
The Backstory I was peacefully implementing authentication for an Angular app, sipping my coffee, feeling productive. I added a simple tap operator to my login method to store the JWT token in localStorage. Easy-peasy, right? Wrong. The injected Stor...
The Problem Every Developer Faces with AI Coding Assistants You've probably experienced this frustration: you ask Claude, Cursor, or any AI coding assistant to write a function, and it confidently generates code that looks perfect at first glance. Bu...
The Backstory So there I was, staring at my shiny new Passbolt installation on Ubuntu 24.04, when that familiar dread crept in: "What happens when (not if) something goes wrong?" After one too many "I'll set up backups tomorrow" moments, I finally de...
TL;DR The custom Reactotron transport for react-native-logs improves logging by handling various message types, adding metadata, and allowing custom prefixes, making your logs more informative and easier to manage. The Backstory Logging is a crucial ...
TL;DR Add parallel: N to your GitLab CI job and pass --shard=${CI_NODE_INDEX}/${CI_NODE_TOTAL} to Playwright to slash your test execution time and keep your team shipping fast. The Backstory Last week, our test suite execution time crossed the dreade...
Error messages are often the first interaction users have with your support system. When they're cryptic, technical, or in the wrong language, they create confusion rather than clarity. That's why I built the Appwrite Exceptions Translator - a lightw...
When deploying Angular 19 apps to Vercel, override the output directory setting to dist/[your-app-name]/browserto avoid the dreaded 404 page if you use the @angular-devkit/build-angular:application builder
There I was, feeling accomplished after building my shiny new Angular 19 app. "Time to deploy!" I thought gleefully. I connected my GitHub repo to Vercel, watched the build succeed with flying colors, and then... 404. The digital equivalent of showing up to a party at the wrong address. What gives, Vercel?
Angular 19 uses the @angular-devkit/build-angular:application builder as the default builder. However, Vercel stubbornly expects you to be using the @angular-devkit/build-angular:browser builder, and its deployment settings are configured accordingly.
// What Angular 19 has in angular.json
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:application",
// ...which outputs files to a different location than Vercel expects
}
}
When Vercel tries to serve your app, it's looking in the wrong place – like a delivery driver dropping your pizza at your neighbor's house, it sucks.
The fix is surprisingly simple: you need to explicitly tell Vercel where your application's output is located. In the Vercel deployment settings, you must override the default output directory path.
Set your Vercel build output directory to:
dist/[your-app-name]/browser
For example, in my case:
dist/play-pulse/browser
This tells Vercel: "Hey, don't look in the usual place. The party's over here!"
This small configuration hiccup can cause a lot of head-scratching and time wasted debugging deployments. Angular's evolution to the new application builder is great for development, but deployment platforms need time to catch up. Understanding these nuances between your build tools and deployment platforms is crucial for smooth DevOps.