Nicholas Agwah’s Post

No doubt, one of the most common and frustrating issues in TypeScript projects is when everything works perfectly in development, but production mode throws a bunch of errors unused components, missing types, or small warnings you ignored earlier. My advice to all junior developers: after adding or updating code, run a build every day. Don’t wait until the end. Building regularly helps you catch hidden issues early, not at the worst possible time right before deployment. Think of it as a quick “reality check” for your code. If it builds cleanly, you’re safe. If not, fix it right away before those tiny mistakes pile up. #TypeScript #WebDevelopment #JuniorDevelopers #CleanCode #BuildBeforePush #DevTips #FullStackDeveloper #LearnToCode #CodeQuality #SoftwareEngineering

npm run dev vs npm run build — The Day I Got Schooled 🤯 As a junior dev, I honestly believed one simple rule: “If the app starts and the terminal stays green ✅ — that means my code is flawless.” And then reality gently slapped me. 😅 I was launching a fresh new project into production. Feeling super confident, I deployed it… everything seemed perfect Then suddenly — bam — an unexpected notification pops up. 💥 “Your project failed the build pipeline.” Wait… what? My dev server was running like a dream. Terminal all clean, no errors. How could this be? 😂 I even double-checked just to feel better. Then I remembered: 👉 “Let me try npm run build once.” The moment I hit enter… chaos. Error after error. Unused variables. Hidden console logs. All those “I’ll handle this later” things came back for revenge 😭 Big realization 👉 ✅ npm run dev shows you the happy path ✅ npm run build shows you the real condition of your code Now, before deploying anything: ✔️ npm run build ✔️ cleanup round ✔️ lint & fix 🧹 Every. Single. Time. 💪 If you’re just starting out — don’t trust the green dev console too much 👀Your future self will be grateful you checked twice. 💡 Takeaway If it runs on your machine but crashes in production… The issue isn’t production. It’s 👇 Your build. 😌 #webdevelopment #frontend #javascript #reactjs #nextjs #cleanCode #softwareengineering #devlife #learninginpublic #techjourney #npm #typescript #juniorToSenior #NpmRunDev #NpmRunBuild

💻 React Devs, ever noticed your production build folder is massive — or worse, your original source code appears in the browser’s DevTools? Here’s a simple yet powerful trick to fix that 👇 GENERATE_SOURCEMAP=false npm run build ✨ What this does: 🚀 Reduces build size 🔒 Keeps your source code secure (no readable code exposed) ⚡ Speeds up the build process ⚠️ A quick note: Avoid disabling source maps in development — it’ll make debugging much harder  💡But wait… what is a Source Map, anyway? 🤔 Think of it as a map that links your minified production code back to your original React files. It’s super useful for debugging — but in production, it’s often unnecessary (and risky). 👉 Have you tried disabling source maps before? Did you notice improvements in build speed or bundle size? Share your experience below 👇 #WebPerformance #ReactJS #CodeOptimization #BuildOptimization #FrontendDevelopment #DeveloperTips #TechCommunity

I finished #NamasteReact by Akshay Saini 🚀 Episode 2: Igniting Our App, where I learned about several important concepts such as … ✅ What is npm? It helps developers install, manage, and share reusable code. npx is used to run npm packages without installing them globally. ✅ package.json vs package-lock.json package.json – Project blueprint (name, version, dependencies, scripts). package-lock.json – Records exact versions of all dependencies; ensures consistency across systems. ✅ Dependencies vs DevDependencies dependencies – Required for the app to run in production. devDependencies – Required only during development (e.g., testing, bundlers). ✅ What is a Bundler? Bundlers like Parcel and Webpack package and optimize code for production. They minify, compress, clean, and remove unused code (tree shaking). ✅ Important Concepts (in bullet points) .parcel-cache → Stores cache for faster rebuilds. /dist folder → Final production-ready optimized code. browserslist → Specifies which browsers your project supports. Hot Module Replacement (HMR) → Updates code instantly without page reload. Tree Shaking → Removes unused code from the final bundle. Transitive Dependencies → Dependencies of your dependencies. .gitignore → Tells Git which files/folders to ignore (like node_modules, dist). npx → Executes packages directly without installing them. #WebDevelopment #ReactJS #Frontend #JavaScript #LearningJourney #Coding #Programming #cleancode #softwareEngineer #Devlife #linkedinjourney #LearningJourney #CareerGrowth #CodeSmarter #NamasteReact #IgnitingOurApp #react #AkshaySaini #reactDom #fullstackdeveloper

A lot of developers still don’t fully understand what actually happens when you run npm run build — and that’s something every dev should know. When you trigger a build, a lot happens under the hood: Loaders and compilers (like Babel, SWC, or TypeScript) transpile your modern JavaScript, TypeScript, or JSX into browser-compatible code. Bundlers (like Webpack, Vite, or Rollup) analyze your dependency graph, bundle everything together, and split it into optimized chunks. Tree shaking removes all the unused imports and dead code, reducing your final bundle size. Minifiers and compressors (like Terser or esbuild) rename variables, strip comments, and compress the code to make it as lightweight as possible. Source maps are generated so you can still debug the production code as if you were looking at your original source. Code splitting ensures your app loads only what’s needed upfront and lazy-loads the rest for better performance. Understanding this process is key to becoming a better developer — it helps you write cleaner, more efficient, and production-ready code. If you’ve never explored what happens behind npm run build, take the time to dig in. You’ll gain a whole new appreciation for how your code gets from your editor to the user’s browser. 🚀

Publishing your first NPM package truly feels like a developer's rite of passage, doesn't it? ✨ It's more than just putting code out there; it's about transforming that utility function you've been copying between projects into a shared solution that can benefit millions worldwide. I recently reflected on the journey from a simple idea to a live package, and the process is surprisingly straightforward, yet incredibly rewarding. From the initial hurdle of finding a unique name (hello, scoped packages! @yourusername/package-name) to the simple `npm init` and `npm publish` commands, each step is a mini-celebration of contribution. It's a powerful reminder that our small solutions can have a massive ripple effect in the JavaScript ecosystem. Plus, that feeling of seeing your package live on the registry? Priceless! What's a small problem you've solved in your daily coding that could become your next big contribution? Let's build and share! If you found this post valuable, give it a like and follow along for more insights on navigating the dev world! 👇 #JavaScript #NPM #WebDevelopment #Coding #DeveloperLife #OpenSource #TechCommunity #PublishYourCode Read more: https://lnkd.in/grt5EMVD

💬 That moment when you think npm is broken… but it’s actually just you. 😅 I was setting up a quick React project and ran this command: npx creat-react-app lm-react-app And boom 💥 — npm threw this scary error: npm ERR! 404 Not Found - creat-react-app I spent a couple of minutes checking the npm registry, internet connection, Node version… Only to realize — I had simply misspelled “create” 🤦♂️ One missing “e”, ten minutes gone. The correct command? npx create-react-app lm-react-app And just like that, everything worked. 💡 Lesson learned: Sometimes, debugging isn’t about deep diving into configs — it’s about spotting the small stuff. Funny how the tiniest typos can waste the most time — yet teach us the most patience 😅 If you’re starting fresh, try this too 👇 npm create vite@latest my-react-app Vite sets up React projects super fast and feels like a breath of fresh air. 🔥 Pro tip for devs: Before you debug the universe, always check for typos first. What’s the smallest mistake that’s ever broken your entire project? I’d love to hear your story 👇 #ReactJS #JavaScript #Frontend #WebDevelopment #CodingLife #Debugging #DeveloperHumor #Vite

How I Cloned Only One React Project from a 900+ Project Repo (Without Downloading Everything!)🤔 Ever had a massive GitHub repo with hundreds of projects, but you only need to update one? 😅 That was me last week :) my repo looked like this 👇 React_Projects/ └── React_Base_Layouts/ ├── 1/ ├── 2/ ├── ... ├── 234/ └── ... I didn’t want to clone 50GB of stuff | I just wanted to work on project #234. So I used a Git feature called Sparse Checkout and it was a game changer.😎 Here’s how I did it (step-by-step): 1️⃣ Create and enter into a new folder :) mkdir React_234 && cd React_234 2️⃣ Initialize Git and set remote :) git init git remote add origin https://lnkd.in/e5epAJEp 3️⃣ Enable sparse checkout :) git config core.sparseCheckout true 4️⃣ Specify the subfolder you want :) echo "React_Base_Layouts/234/" >> .git/info/sparse-checkout 5️⃣ Pull only that directory :) git pull origin main ✅ Now your local folder looks like this :) React_Base_Layouts/234/ 6️⃣ Move in, install, and run :) cd React_Base_Layouts/234 npm install npm run dev 7️⃣ Update the code, Add and Commit your changes :) git add React_Base_Layouts/234 git commit -m "Updated ... 234" git push origin main 🔥Result: You’ve just cloned and updated one project out of hundreds => cleanly, fast, and without clutter. 😎 Perfect for devs managing large React/Next.js monorepos or reusable layout libraries. Have you tried git sparse-checkout before? It’s one of those underrated Git tricks that makes you feel like a wizard 🧙♂️ #React #Git #WebDevelopment #Frontend #ReactJS #NextJS #DeveloperTips #CodingLife #OpenSource #Productivity #GitHub

🚀 npm start vs npm run — What’s the Difference? If you’ve worked with Node.js or React, you’ve definitely used these commands. But do you really know how they differ? 🤔 🟢 npm start It’s a shortcut command that automatically runs the “start” script defined in your package.json file. You don’t need to type the word run — it’s built in as a special shortcut. 🟣 npm run This command is used to execute any custom script you define in your project. You can use it for tasks like build, test, deploy, or dev. In simple terms — npm run is used for everything other than the default start script. ⚙️ Quick Recap ✅ npm start → Shortcut for running the “start” script ✅ npm run → Used to run other custom scripts 💡 In short: npm start is for the default script, while npm run gives you flexibility to run any custom command. ✨ Small details like this make you a smarter developer every day! Keep learning, keep building 🚀 #NodeJS #JavaScript #WebDevelopment #ReactJS #CodingTips #npm #DeveloperCommunity #CodeNewbie #100DaysOfCode #FrontendDevelopment #TechLearning

npm run dev vs npm run build! As a junior dev, I used to think: “If my app spins up and the terminal is green ✅ — I’m good. Zero bugs.” Then reality hit… Working on a production project, I pushed changes, opened a PR, feeling confident. Suddenly — got that weird message! 💥 “Hey bro, your changes broke the CI pipeline.” 😳 Me? Impossible. My terminal was green! I even tried to deny it at first 😂 Then my teammate calmly said: 👉 “Run npm run build and check again.” Boom. Errors everywhere. Unused variables. Lingering logs. Stuff I thought didn’t matter “for now.” Lesson learned 👉 ✅ npm run dev helps you develop ✅ npm run build tells you if your code can survive the real world Now before pushing any code: ✔️ npm run build ✔️ clean up ✔️ lint & fix 🧹 Every. Single. Time. 💪 If you're starting out — don’t trust only the green dev console 👀 Your future self (and your team) will thank you! Oluwasegun Samson ❤️