Custom Gutenberg block changes not updating after npm start

# Postmortem: Custom Gutenberg Block Changes Not Updating After `npm start`

**Summary**
- JavaScript changes in a custom Gutenberg block created with `@wordpress/create-block` aren't reflected in the WordPress editor despite running `npm start`.
- Occurs in a local WordPress environment using XAMPP, with no active caching plugins.

**Root Cause**
- **Hard browser caching** of JavaScript files preventing updated assets from loading
- **Missing cache-busting parameters** in asset URLs during development builds
- **Undetected build errors** failing to trigger automatic browser refreshes

**Why This Happens in Real Systems**
1. Browsers aggressively cache static assets (JS/CSS) to improve performance
2. Development tools (like `webpack-dev-server`) require specific configurations to bypass caching mechanisms
3. Build processes may succeed silently despite errors in watch mode (`--watch` or `start`)
4. Infrastructure limitations (e.g., XAMPP's localhost environment) exacerbate caching behavior

**Real-World Impact**
- **Wasted development time**: Engineers rebuild unchanged code
- **False debugging cycles**: Developers investigate non-existent "bugs" from outdated code
- **Loss of trust**: Team questions toolchain reliability
- **Production risks**: Undetected build issues may carry over to deployment

**Example** or Code
Typical `webpack.config.js` gap in cache handling:
```javascript
// Missing cache-busting in development mode
module.exports = {
  // ...
  output: {
filename: '[name].js' // Should be '[name].[contenthash].js' in prod → leaves dev vulnerable
  }
}

Developer Console evidence of caching:

[hmr] Update failed: Loading hot update chunk vendor failed.
(window.bundle.js:1234)

How Senior Engineers Fix It

1. Force cache bypass: Append timestamp parameter to script URLs

   // In webpack.config.js
   devServer: {
   hot: true,
   devMiddleware: {
   writeToDisk: true // Ensures files update in PHP environment
   }
   }

2. Enable aggressive cache busting:

   # Add to package.json
   "scripts": {
   "start": "wp-scripts start --hot --config-cache=false"
   }

3. Update Browser Policy:
   • Configure webpack-dev-server headers: Cache-Control: no-store
   • Enable “Disable cache” in browser DevTools (Network tab)
4. Validation layer:

   rm -rf node_modules/.cache  # Clear webpack cache

Why Juniors Miss It

1. Assumption that npm start handles all refresh logic automatically
2. Unfamiliarity with browser caching mechanisms beyond basic Ctrl+F5
3. Debugging focus limited to code rather than toolchain behavior
4. *Overlook webpack-dev-server logs for “not updated” warnings
5. Environment blindness: Not considering XAMPP’s file handling differences