DEV Community: Muhammad Hamid Raza

VS Code 1.128 Is Here: Multi-Chat Agent Sessions, Copilot Vision, and OS-Level Shortcuts 🚀

Muhammad Hamid Raza — Wed, 08 Jul 2026 16:38:05 +0000

Ever had five different conversations going with an AI assistant, all about the same project, but scattered across five separate tabs? You lose track of which chat had the good idea. You forget which one was just testing something weird. It gets messy fast.

VS Code 1.128 (released July 8, 2026) tackles exactly that problem, along with a few other genuinely useful upgrades. Let's walk through what's new, in plain language. 😊

What Is VS Code 1.128?

VS Code 1.128 is simply the latest update to Visual Studio Code, the free code editor made by Microsoft that millions of developers use every day.

Think of it like a phone getting a software update. Your phone still works the same way, but suddenly you have new camera features or better battery controls. VS Code updates work the same way: same editor you know, but with new tools added on top.

This release focuses heavily on Chat and Agents, the part of VS Code where you talk to an AI to help you write code, debug, or answer questions.

Why This Release Matters

If you use AI chat inside your editor, you already know the small annoyances: switching between chats, losing context, or not being able to attach an image when you need to show a bug visually.

This update directly fixes those friction points. It also adds a shortcut feature that goes beyond the editor itself, and gives teams more control over how AI usage is tracked. In short: less busywork, more focus on actual coding.

Benefits with Real-Life Examples

Multiple chats in one Claude session 💬
Instead of opening a brand-new session every time you want to try a different approach, you can now keep related chats grouped together. Example: one chat adds a /health endpoint to your Express app, while a peer chat writes tests for it at the same time, and a forked chat tries an alternative way to build the same feature. All three stay organized under one session instead of cluttering your session list.
Quick chats without opening a workspace ⚡
Sometimes you just want to ask a quick question, not open an entire project folder. Now you can start a chat in the Agents window without picking a workspace first. It's like asking a coworker a quick question in the hallway instead of walking them to your desk.
Copilot Vision, now generally available 👀
You can paste, drag, or drop images and PDFs straight into Chat. Say you have a screenshot of a broken UI layout — you can hand that directly to the agent instead of typing out a long description of what's wrong.
Read-only subagent chats (Preview)
When an agent delegates work to helper subagents, you can now watch their progress in a read-only view without accidentally interrupting them. Useful when you want visibility without micromanaging.
Configurable browser tab placement 🔧
You can choose whether integrated browser tabs open in your active editor group, a dedicated side group, or their own window. Small thing, but it keeps your workspace from feeling cluttered.
OS-level keyboard shortcuts
You can now set up shortcuts that trigger VS Code commands even when VS Code isn't the focused window. For example, a cmd+shift+a shortcut on macOS that opens the Agents window instantly, no matter what app you're currently in.

Beginner Approach vs Better Approach: Managing Multiple AI Conversations

Beginner approach: Open a new top-level session every time you want to try a different idea. Result: ten sessions, no idea which one has the code you actually want to keep.

Better approach (as of 1.128): Use multiple chats inside one Claude session. Add a chat, fork from an earlier turn, or run chats in parallel — all while keeping everything grouped under one session that's easy to find later.

This isn't about one method being "wrong." It's just that as your AI usage grows, organized sessions save real time.

Best Tips for Using These New Features

✅ Try forking a chat before starting a totally new session. If an idea works, you keep it. If it doesn't, you didn't lose your original conversation.
✅ Use quick chats for one-off questions. Don't open a whole workspace just to ask something simple.
✅ Turn on OS-level shortcuts sparingly. They're powerful, but pick a key combo that doesn't clash with shortcuts your other apps already use.
✅ If you're on a team, check with your admin about the new OpenTelemetry settings for Copilot — managed settings will always override your personal ones.
⚠️ Remember: chats without a workspace only work when the agent host is enabled through the chat.agentHost.enabled setting.

Common Mistakes People Make

Assuming every chat needs its own session. This gets overwhelming fast. The new multi-chat model exists specifically so you don't have to do this anymore.
Forgetting that BYOK (Bring Your Own Key) models don't use utility models by default. If you're using your own key as the main agent and notice chat titles or commit messages aren't generating, it's because chat.byokUtilityModelDefault needs to be set. It's not a bug, it's a default behavior worth knowing about.
Not checking the modelOptions settings when using Custom Endpoint models. If your provider has strict parameter requirements, setting temperature or top_p incorrectly (or forgetting to set them to null when needed) can cause request failures.
Ignoring the difference between sideGroup and window for browser tabs. People often pick one, get annoyed, and don't realize there's a setting to change it.

Wrapping Up

VS Code 1.128 is a solid, practical update. Multi-chat agent sessions make working with Claude in VS Code more organized. Copilot Vision going GA means images and PDFs are now a natural part of your chat workflow. And OS-level shortcuts mean VS Code can be one keypress away, even when it's not in focus.

None of this reinvents the editor. It just removes small annoyances that add up over a normal coding day, which honestly is what good updates should do. 💡

If you found this useful, feel free to share it with a fellow developer who's still juggling ten browser tabs of AI chats. And if you want more practical, no-fluff dev content like this, check out more posts at hamidrazadev.com.

Got a favorite feature from this release? Drop a comment below and let's talk about it! 👇

The New HTTP QUERY Method: Why GET and POST Weren't Enough

Muhammad Hamid Raza — Sun, 05 Jul 2026 10:19:28 +0000

Have you ever built a search feature and hit a wall because your filters were too long for a URL? 😅 Yeah, me too. You start with a clean GET /search?q=... request, everything's happy, and then someone adds ten more filters and suddenly your URL looks like a ransom note.

Most of us just switch to POST at that point and move on with our lives. It works, sure. But it always felt a little... off. POST is meant for creating or changing things, not for asking a question.

Turns out the IETF felt the same way. In June 2026, they published RFC 10008, which defines a brand-new HTTP method called QUERY. It's built specifically to fix this exact headache. Let's break down what it is, why it matters, and how you'd actually use it. 🚀

What Is the HTTP QUERY Method?

Think of HTTP methods like different types of requests you can make to a waiter at a restaurant.

GET is like pointing at a menu item. Simple, safe, repeatable — you can point at it a hundred times and nothing changes.
POST is like telling the waiter "surprise me, and also charge my card." It might change something, and doing it twice could mean two charges.
QUERY is the new one: it's like handing the waiter a detailed written note describing exactly what you want, but with a promise attached — "this is just a question, not an order, so ask it as many times as you need."

In technical terms, QUERY lets you send a request with a body (just like POST), but it's explicitly marked as safe and idempotent — meaning it won't change server state, and repeating it is completely fine.

Here's what it looks like in practice:

QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded

q=foo&limit=10&sort=-published

Compare that to the old GET-with-a-giant-URL approach:

GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.org

Same intent, but QUERY moves the data into the body, where it belongs when things get complex.

Why This Topic Matters

You might be thinking, "okay, cool, but why should I care about one new HTTP verb?" Fair question. Here's the real-world pain it solves:

1. URL length limits are real. The spec itself points out that request URIs often need to stay under roughly 8000 characters. If your search has a dozen filters, a full-text query, and some tags, you can blow past that fast.

2. URLs get logged everywhere. Proxies, browser history, server logs, analytics tools — they all love to record URLs. If your "query" contains anything sensitive, that's a problem. A request body is far less likely to get logged the same way.

3. POST breaks caching and safe retries. If your query is actually a POST, browsers and caches can't safely retry it after a dropped connection, because POST might have side effects. QUERY tells everyone in the chain: "relax, this is just a read."

If you've ever debugged a flaky search endpoint or worried about sensitive data leaking into a URL, this method was made for you.

Benefits with Real-Life Examples

Cleaner architecture for complex searches. Imagine an e-commerce filter with brand, price range, size, color, and rating. With QUERY, all of that lives in a structured request body instead of a mile-long URL string. Way easier to read and maintain.
Safe automatic retries. Since QUERY is idempotent, your HTTP client (or a proxy) can safely resend the request if the connection drops — no risk of accidentally triggering something twice, unlike a risky POST retry.
Built-in caching support. RFC 10008 explains that responses to QUERY requests are cacheable, similar to GET. So a cache can store the result and serve it again for an identical query, saving your server some work.
Content negotiation like a champ. The Accept-Query header lets a server advertise which query formats it understands — say, application/sql or application/jsonpath — so clients know exactly what to send before they even try.
Optional shareable URLs. A server can still hand back a Location header pointing to a URI that represents the same query, so you can bookmark or share a query result if you want to — you're just not forced to cram everything into the URL upfront.

GET vs POST vs QUERY: Quick Comparison

	GET	QUERY	POST
Safe (no side effects)	Yes	Yes	Maybe not
Idempotent (safe to repeat)	Yes	Yes	Maybe not
Has a request body	No defined meaning	Yes, expected	Yes, expected
Cacheable	Yes	Yes	Only in special cases
Good for long/complex queries	No	Yes	Sort of, but semantics are unclear

The short version: QUERY gives you POST's flexibility (a body for your data) with GET's safety guarantees (safe, idempotent, cacheable). It really is the best of both worlds for read-only operations.

Best Tips for Using QUERY

Always set a Content-Type header. The spec is strict here — if it's missing or doesn't match your actual body content, the server is expected to reject the request with a 4xx error.
Check for support first. You can send an OPTIONS request and look at the Allow header, or check for an Accept-Query header, to see if a server actually supports QUERY before relying on it.
Use it for reads only. If your request changes data on the server, that's not a QUERY — stick with POST, PUT, or PATCH for that.
Take advantage of conditional requests. Just like GET, QUERY supports things like If-Modified-Since, so you can avoid re-downloading a query result that hasn't changed.
Don't put sensitive data in a Location URI. If your query result gets a temporary URL, make sure that URL itself doesn't leak sensitive query details.

Common Mistakes People Make

Mistake 1: Treating QUERY like a normal POST.
It's tempting to just swap the method name and call it done. But since QUERY promises to be safe and idempotent, any implementation that changes server state under the hood is technically breaking the contract — even if nothing crashes right away.

Mistake 2: Forgetting that QUERY needs CORS preflight.
If you're calling this from a browser across origins, QUERY isn't in the CORS-safelisted method list, so your browser will send a preflight OPTIONS request first. Skipping this consideration can lead to confusing failures in production.

Mistake 3: Assuming every server supports it already.
QUERY is brand new as of this RFC. Many servers, frameworks, and even browsers won't support it out of the box yet. Always check for support instead of assuming.

Mistake 4: Ignoring the Accept-Query header.
If a server tells you exactly which formats it accepts, use that information instead of guessing and getting a 415 Unsupported Media Type response.

Wrapping Up

The HTTP QUERY method fills a real gap that a lot of developers have quietly worked around for years — usually by misusing POST or fighting with URL length limits. Now there's an official, standardized way to send a safe, idempotent request with a full body, and get proper caching and retry behavior for free.

It's not going to replace GET or POST. It's simply the right tool for a very specific job: asking a detailed question without changing anything. If you build APIs with search, filtering, or reporting features, this is worth keeping on your radar as tooling and framework support catches up.

If this cleared things up for you, I'd love for you to share it with a fellow developer who's fighting with a 3,000-character search URL right now. 😄 You can find more practical, beginner-friendly dev content over at hamidrazadev.com — drop a comment if you have questions or your own QUERY use case!

Visual Studio Code 1.127: Everything New in the July 2026 Update

Muhammad Hamid Raza — Wed, 01 Jul 2026 10:11:14 +0000

If you open Visual Studio Code every day, you know the feeling. A new update appears, you skim the release notes, promise yourself you'll read them later... and then get back to debugging that one mysterious error that somehow disappeared after adding a console.log() 👀.

The Visual Studio Code 1.127 release brings several meaningful improvements, especially if you use AI-powered development, build web applications, or simply want a smoother coding experience. So what's actually worth your attention? Let's break it down. 🚀

What Is Visual Studio Code 1.127?

Visual Studio Code 1.127 is the July 2026 update of Microsoft's popular code editor.

Like most VS Code releases, this update focuses on improving developer productivity instead of introducing flashy changes. Many improvements make existing workflows smoother, especially around AI agents, browser integration, and session management.

Whether you're a student learning programming or an experienced developer working on large projects, these updates aim to reduce friction while writing and testing code.

Why This Update Matters

Small improvements add up.

Imagine spending a few seconds less every time you organize AI sessions, review changes, or test your web app. Those seconds become minutes, and those minutes become hours over weeks of development.

This release helps developers:

spend less time switching between tools
organize AI workflows more easily
test browser-based applications inside VS Code
understand AI usage more clearly
work with fewer interruptions

None of these features magically write perfect software. They simply make the development process a little smoother.

What's New in Visual Studio Code 1.127

🌐 Browser Tools for AI Agents Are Now Generally Available

One of the biggest highlights is that browser tools for AI agents are now generally available.

Agents can now:

Open web pages
Read page content
Take screenshots
Click buttons
Navigate websites
Help validate web applications

For frontend developers, this reduces the need to constantly switch between VS Code and an external browser during certain AI-assisted workflows.

🔒 Per-Site Browser Permissions

The integrated browser now supports individual permissions for each website.

Supported permissions include:

Camera
Microphone
Geolocation
Clipboard
Bluetooth
USB devices
Sensors

Instead of allowing everything globally, VS Code asks for permission per site, similar to modern web browsers.

This gives developers better control while testing browser features.

📂 Better Agent Session Organization

If you've ever had several AI sessions open at once, you know how quickly things become messy.

VS Code 1.127 introduces:

Custom session groups
Drag-and-drop organization
Pinning sessions
Moving multiple sessions together
Collapsible groups

Think of it like organizing folders on your desktop instead of leaving everything scattered everywhere.

💬 Chat Input Banners

The Agents window can now display helpful banners above the chat input.

Examples include:

Failed CI checks
New pull request comments

Instead of hunting through different windows, you can respond directly inside your current workflow.

💰 Subagent Credit Visibility

When AI delegates work to subagents, you can now hover over them to see how many AI credits were used.

This adds more transparency and helps developers better understand resource usage.

✨ Improved Multi-Chat Sessions

Multi-chat sessions continue to improve with several useful additions:

Create multiple chats inside one session
Close and reopen chats
Permanently delete chats
Fork conversations into peer chats
Better progress tracking across chats

This makes complex AI-assisted development easier to organize.

⚡ Better Session Layout

Several interface improvements make sessions easier to work with:

Consistent header buttons
Cleaner workspace indicators
Combined file change summaries
Automatic focus on the chat input when switching sessions

These aren't dramatic changes, but they remove small annoyances that developers experience every day.

🛠️ /troubleshoot for AI Sessions

If an AI session behaves unexpectedly, you can now use:

/troubleshoot

The command analyzes session logs and helps explain issues such as:

ignored custom instructions
slow responses
unexpected behavior

Instead of guessing what happened, you get more useful diagnostic information.

🧪 Terminal Sandboxing

On macOS and Linux, many agent-invoked terminal commands now run inside a sandbox by default.

This means:

restricted filesystem access
blocked network access
fewer approval prompts for safer commands

Commands requiring broader access still request permission.

🤖 Built-in Ollama Provider Deprecation

The built-in Ollama provider has been deprecated.

If you use Ollama inside VS Code, the recommended approach is now the official Ollama extension.

This change helps model providers ship updates faster without waiting for VS Code releases.

Benefits with Real-Life Examples

✅ Cleaner AI workflows
- Instead of scrolling through dozens of sessions, you can organize them into logical groups.
✅ Safer browser testing
- When testing a web app that requests camera access, permissions are granted per site instead of globally.
✅ Less context switching
- Pull request comments and CI failures appear directly where you're already working.
✅ Better transparency
- Credit usage helps teams understand how AI resources are being consumed.
✅ Improved debugging
- The /troubleshoot command provides insights instead of leaving you guessing.

Visual Studio Code 1.127 vs Earlier Versions

Earlier Versions	VS Code 1.127
Basic AI session management	Better grouping and drag-and-drop organization
Browser tools in preview	Browser tools generally available
Limited browser permissions	Per-site permission model
Less visibility into AI usage	Subagent credit information
Simpler multi-chat experience	Improved multi-chat management

Best Tips

✅ Do

Keep your AI sessions organized with groups.
Use browser tools when validating web applications.
Review permission prompts before granting access.
Try /troubleshoot if AI responses seem unusual.
Update extensions alongside VS Code for the best compatibility.

❌ Don't

Ignore permission requests without reading them.
Leave dozens of sessions open if they are no longer needed.
Assume AI-generated changes are always correct. Review them carefully.
Forget to migrate if you're still using the deprecated built-in Ollama provider.

Common Mistakes Developers Make

Ignoring release notes

Many developers install updates without checking what's new.

Even spending five minutes reading the highlights can reveal features that save time every day.

Treating AI like autopilot

AI tools are helpful, but they still need human review.

Always verify generated code before committing it.

Keeping messy sessions

Leaving every conversation open makes it harder to find the work that actually matters.

Grouping sessions keeps projects much easier to navigate.

Forgetting extension updates

Some new VS Code capabilities work best when related extensions are also up to date.

Keeping both current helps avoid compatibility issues.

Final Thoughts

Visual Studio Code 1.127 isn't about huge visual changes. Instead, it focuses on refining everyday development.

The improvements to AI agents, browser tools, permissions, session management, and diagnostics are practical additions that can make daily coding feel a little more organized and efficient.

If you spend hours inside VS Code each week, even small workflow improvements are worth exploring.

If you found this article helpful, consider sharing it with other developers who might benefit from it. You can also discover more practical developer tutorials, guides, and articles at https://hamidrazadev.com. Happy coding! 🚀

DX Matters Too: Why Developer Experience Deserves the Same Love as UX

Muhammad Hamid Raza — Sun, 28 Jun 2026 11:06:52 +0000

Everyone talks about UX. But who's talking about the people building the product? 🤔

Introduction

You've heard it a thousand times: "Make it a great experience for the user." And yes, that matters. Nobody wants a confusing app.

But here's something we don't say out loud enough — what about the developer sitting at 11 PM, fighting a broken CLI, cryptic error messages, and documentation that reads like a legal contract?

Developer Experience, or DX, is the UX for the people who build things. And for a long time, it's been treated like an afterthought.

If you've ever rage-quit a library because the docs were useless, spent hours just getting a "Hello World" running, or stared at an error message that told you absolutely nothing — you've experienced bad DX firsthand.

So let's talk about it. Because DX deserves the spotlight. 🚀

What Is Developer Experience (DX)?

Developer Experience is how a developer feels and works when using a tool, API, framework, SDK, or platform.

Think of it like this: UX is how your users feel using your app. DX is how developers feel building it.

If a user gets confused by a button, that's a UX problem.

If a developer gets confused by your package setup, broken error messages, or missing documentation — that's a DX problem.

DX covers things like:

How easy is it to install and get started?
Are error messages actually helpful?
Is the documentation clear and complete?
Does the API feel intuitive and consistent?
How fast is the local development feedback loop?
Are there good examples to follow?

It's not just about "developer happiness" (though that matters too). Good DX directly affects how fast teams ship, how many bugs slip through, and whether people adopt your tool at all.

Why Developer Experience Actually Matters

Here's a truth most product managers and business owners overlook:

Developers are users too.

When a developer struggles to use your API, SDK, or platform, they don't push through it out of loyalty. They Google the competition, find something easier, and move on.

And beyond adoption — bad DX slows everything down internally too.

When your team's own development workflow is painful, onboarding new engineers takes weeks instead of days. Simple tasks become complicated. Simple bugs become mysterious. Time that could go into building features goes into fighting the environment.

Good DX is a multiplier. When your dev tooling, APIs, and internal systems are clean and intuitive:

Developers ship faster
Bugs get caught earlier
Onboarding becomes smooth
Code stays consistent
Teams stay motivated

And that directly improves the final product — which means, ironically, good DX leads to better UX in the end.

Real Benefits of Prioritizing DX (With Examples)

✅ Faster onboarding

When your README is clear, your CLI has a guided setup, and your examples actually work — a new team member can be productive in hours instead of weeks. Think of how Vercel's npx create-next-app gets you running in under two minutes. That's intentional DX at work.

✅ Better error messages mean fewer lost hours

A good error message tells you what went wrong, where, and ideally how to fix it. A bad one says Error: undefined. Rust's compiler is famous for giving helpful, readable error messages. Developers genuinely appreciate that.

✅ Clear docs reduce the "wall of shame"

The "wall of shame" is that moment where you close the docs tab and paste into ChatGPT instead. Stripe's API documentation is a gold standard — clear, well-organized, and full of real examples. When docs are good, developers trust the product.

✅ Intuitive APIs reduce cognitive load

When an API behaves consistently and predictably, developers spend less mental energy remembering edge cases. React's hook design, for example, follows consistent rules that feel natural once learned.

✅ Fast feedback loops keep developers in flow

Hot reloading, instant previews, fast build times — these aren't luxuries. They're productivity tools. When you break a developer's flow with a 30-second rebuild every save, you're draining energy and focus.

UX vs DX: Two Sides of the Same Coin

People sometimes treat UX and DX as competing priorities. They're not. They're complementary.

Area	UX Focus	DX Focus
Who is the user?	End users (customers, visitors)	Developers (builders, integrators)
Key concern	Is the interface easy and pleasant?	Is the tooling easy and productive?
Measured by	Task success, satisfaction, retention	Onboarding time, error rate, adoption
Common pain points	Confusing UI, slow load, broken flows	Bad docs, cryptic errors, fragile setup
Tools that help	Figma, user testing, analytics	CLI tools, SDKs, sandboxes, good docs

The best products invest in both. A beautiful app built on a nightmare codebase will slow down every future improvement. Great DX makes it possible to maintain great UX over time.

Best Practices: How to Improve DX

💡 Write documentation like you're teaching a friend

Don't assume knowledge. Explain what something does, why it exists, and show a working example. Add comments inside code samples. One good example beats three paragraphs of explanation.

💡 Make error messages human-readable

Every error should answer: what went wrong, where did it happen, and what should I do next? If your error message is just a stack trace with no context, it's not helpful.

💡 Build a great getting-started experience

The first five minutes are everything. If a developer can't see results fast, they'll leave. Offer a working starter template, a one-command setup, or a sandbox playground.

💡 Be consistent across your API or codebase

If you name one thing getUserById, don't name the next one fetchUserData. Consistency lets developers predict how things work. Inconsistency forces them to check docs for every single call.

💡 Listen to developer feedback

If multiple developers ask the same question, that's a DX problem — not a developer problem. Update your docs, improve the error, or simplify the flow.

💡 Test your own DX

Hand your tool to a new developer and watch them use it without help. Where do they get stuck? That's where your DX needs work.

Common Mistakes That Kill Developer Experience

❌ Assuming developers will "figure it out"

No, they won't. They'll Google it. If they find a better alternative, they'll use that instead. Good DX is never accidental — it's designed.

❌ Writing docs after the fact

Documentation written as an afterthought shows. It's usually incomplete, outdated, or just confusing. Treat docs as part of the product, not a checkbox you tick before launch.

❌ Returning vague errors

Something went wrong is not an error message. It's an apology that doesn't help. Every error state should give the developer something to act on.

❌ Neglecting the local development experience

If your app needs 12 steps to run locally — environment variables, Docker containers, manual seed data, two separate config files — that's a DX issue. Simplify wherever you can.

❌ Breaking changes without clear migration paths

Introducing a breaking change and just saying "update your code" is painful. Provide changelogs, migration guides, and deprecation warnings. Developers respect that.

❌ Ignoring the onboarding experience for your own internal systems

DX isn't just for public-facing tools. If your internal codebase, CI/CD setup, or component library is confusing, new team members suffer. Internal DX matters just as much.

Conclusion

Here's the bottom line: UX and DX are both about respect.

UX is about respecting your users' time and attention. DX is about respecting your developers' time and energy.

When you invest in Developer Experience, you're not just making life easier for engineers. You're building a foundation that lets great products get shipped faster, maintained better, and improved continuously.

The next time someone says "let's focus on the user experience," add this to the conversation: "And let's also take care of the people building it."

Because when developers feel good about the tools they use and the environment they work in, the things they build are better. And that? That's good for everyone. 😊

If this gave you a new way to think about development, I'd love for you to check out more articles at hamidrazadev.com. There's a lot more on frontend development, tooling, and building things the right way.

If it was useful — share it with a developer friend who deserves better DX. They'll appreciate it. 🙌

All npm Dependency Types Explained: dependencies, devDependencies, peerDependencies, and More

Muhammad Hamid Raza — Sat, 27 Jun 2026 04:45:22 +0000

Ever stared at a package.json file and wondered why some packages live under dependencies and others under devDependencies? 🤔 And then you spotted peerDependencies hiding at the bottom like a ghost you didn't know existed?

You are not alone. This trips up beginners and even mid-level developers who never stopped to think about it deeply.

Here is the truth: putting a package in the wrong dependency type does not just feel wrong — it can bloat your production build, break someone else's project, or cause weird version conflicts that are painful to debug.

So let's fix that today. By the end of this post, you will know exactly where every package belongs and why it matters.

What Is a Dependency in npm?

A dependency is any external package your project needs to do its job.

Think of it like ingredients in a recipe. Some ingredients go into the final dish (the user eats them). Some are just tools you used while cooking — like a mixer or a timer — that the guest never sees.

npm uses your package.json file to track all of these ingredients in different labeled boxes, depending on when and where they are needed.

All Dependency Types in npm

Here is the full picture — every field that can appear in your package.json:

Type	Key in package.json	When It Is Used
Runtime dependency	`dependencies`	In production, always
Dev-only dependency	`devDependencies`	Only during development
Peer dependency	`peerDependencies`	Shared with the host project
Peer metadata	`peerDependenciesMeta`	Marks a peer dep as optional
Optional dependency	`optionalDependencies`	Nice to have, not required
Bundled dependency	`bundledDependencies`	Shipped inside your package

And separately, npm gives you install-time save flags that control which category a package lands in. We will cover those too.

Let's break each one down properly.

1. `dependencies` — The Production Essentials

These are packages your app needs to run in production. Without them, your app breaks.

"dependencies": {
  "express": "^4.18.2",
  "axios": "^1.6.0",
  "react": "^18.2.0"
}

Real example: If you are building a React app, React itself goes here. If you are building an API with Express, Express goes here. Your users and servers need these packages to exist at runtime.

Install command:

npm install express
# or
npm install --save express

✅ Rule: If removing this package makes your app crash or fail in production, it belongs in dependencies.

2. `devDependencies` — The Dev-Time Helpers

These are packages you only need while building, testing, or writing code. They never go to production.

"devDependencies": {
  "eslint": "^8.57.0",
  "typescript": "^5.4.2",
  "jest": "^29.7.0",
  "vite": "^5.2.0"
}

Real example: ESLint checks your code style. Jest runs your tests. Vite builds your project. None of these run when a user opens your app in the browser. They are just tools you use at your desk.

Install command:

npm install --save-dev eslint
# or
npm install -D eslint

✅ Rule: If the package is only used for linting, testing, compiling, or bundling — it belongs in devDependencies.

Why does this matter?

When someone deploys your app using npm install --production (or sets NODE_ENV=production), npm skips devDependencies. This keeps your production environment lean and fast. Shipping test runners to production is a waste of space and a security risk.

3. `peerDependencies` — The Sharing Agreement

This one is mostly for library and plugin authors, not app developers.

When you build a library (say, a custom React component library), you expect the project using your library to already have React installed. You do not want to bundle your own copy of React — that would cause version conflicts and bloat.

So instead of adding React to your dependencies, you declare it as a peer dependency.

"peerDependencies": {
  "react": ">=17.0.0",
  "react-dom": ">=17.0.0"
}

Real example: A package like react-query does not install its own React. It says: "Hey, I expect you to already have React. Make sure the version is compatible."

Install command:

Peer dependencies are NOT automatically installed by npm (in npm v7+, npm will warn you if they are missing but tries to install them). In older versions, you had to install them yourself.

✅ Rule: If you are writing a package or plugin that relies on the host project having a dependency, use peerDependencies.

4. `peerDependenciesMeta` — The Peer Dependency Modifier

This one is small but important. It does not stand alone — it works alongside peerDependencies to mark specific peer deps as optional.

By default, if a peer dependency is missing, npm throws a warning (or error). But sometimes you want to say "React Native is a peer dep, but only if the user is building a React Native project." That is where peerDependenciesMeta comes in.

"peerDependencies": {
  "react": ">=17.0.0",
  "react-native": ">=0.70.0"
},
"peerDependenciesMeta": {
  "react-native": {
    "optional": true
  }
}

Real example: A UI library that supports both web and React Native can list react-native as an optional peer dependency. Web-only users won't get a warning about a missing package they don't need.

✅ Rule: Use peerDependenciesMeta when you have peer dependencies that are only relevant in certain environments. It silences unnecessary warnings for users who don't need them.

5. `optionalDependencies` — The Nice-to-Have

These are packages your project can use if available, but your app will not crash if they fail to install.

"optionalDependencies": {
  "fsevents": "^2.3.3"
}

Real example: fsevents is a native file-watching module that only works on macOS. Some packages list it as optional because it improves performance on Mac, but the package still works fine on Windows and Linux without it.

Install command:

npm install --save-optional fsevents

✅ Rule: If the package is a performance boost or platform-specific extra — not a core requirement — use optionalDependencies. But make sure your code handles the case where it is absent.

6. `bundledDependencies` — The Package-in-a-Package

This one is rare. Also written as bundleDependencies (both work).

It is a list of package names that will be physically bundled inside your npm package when you publish it with npm pack or npm publish. Instead of letting the user's npm fetch them from the registry, they come bundled with your package.

"bundledDependencies": [
  "some-internal-util"
]

Real example: If you have a private internal package or a fork of a package you modified, you can bundle it directly so users always get the exact version you tested with — without depending on the registry.

✅ Rule: Use bundledDependencies only when you need to ship specific packages alongside your own — like private utilities or heavily patched forks. Most developers never need this.

7. npm Install Save Flags — How Each Type Gets Added

Every dependency type has a matching npm install flag that controls where the package lands in package.json. This is the part most tutorials skip.

Here is the complete reference:

Flag	Shorthand	Where It Saves	Example
`--save`	`-S`	`dependencies`	`npm install axios --save`
`--save-dev`	`-D`	`devDependencies`	`npm install jest -D`
`--save-optional`	`-O`	`optionalDependencies`	`npm install fsevents -O`
`--save-peer`	(none)	`peerDependencies`	`npm install react --save-peer`
`--save-bundle`	`-B`	`bundledDependencies`	`npm install util -B`
`--save-exact`	`-E`	Saves exact version (modifier)	`npm install lodash -E`
`--no-save`	(none)	Does not save to package.json	`npm install chalk --no-save`

Let's talk about each one briefly.

`--save` or `-S` (Default since npm v5)

This saves the package to dependencies. Before npm version 5, you had to write --save explicitly or the package would install but not appear in package.json. Since npm v5, running npm install package-name does the same thing automatically.

npm install express        # same as:
npm install express --save
npm install express -S

All three do the exact same thing today. You will still see --save in older tutorials — it is not wrong, just no longer necessary.

`--save-dev` or `-D`

Saves to devDependencies. Use this for linters, test runners, type checkers, and build tools.

npm install typescript --save-dev
npm install typescript -D

`--save-optional` or `-O`

Saves to optionalDependencies. The package is installed if possible but skipped without an error if it fails.

npm install fsevents --save-optional
npm install fsevents -O

`--save-peer` (npm v7+)

Saves to peerDependencies. This flag was added in npm v7. Before that, you had to manually edit package.json to add peer dependencies.

npm install react --save-peer

⚡ Note: This is a relatively newer flag. If you are using an older npm version, you may need to add peerDependencies manually.

`--save-bundle` or `-B`

Saves to bundledDependencies. The package name is added to the array (not as a key-value pair like others).

npm install some-util --save-bundle
npm install some-util -B

`--save-exact` or `-E`

This is a modifier, not a category. It does not change which section the package goes into — it just removes the ^ version prefix and saves the exact version number instead.

npm install lodash -E          # saves "lodash": "4.17.21" instead of "^4.17.21"
npm install lodash -D -E       # exact version saved to devDependencies

Use this when you need pinned, reproducible installs and do not want any automatic minor or patch updates.

`--no-save`

Installs the package into node_modules but does not write anything to package.json. Useful for quick one-off testing of a package without committing it to your project.

npm install some-package --no-save

Quick Visual Summary

package.json dependency fields:

Your project (package.json)
│
├── dependencies            → Runs in production. User needs it. ✅
├── devDependencies         → Dev-only. Never ships to production. 🔧
├── peerDependencies        → For library authors. "Bring your own." 📦
├── peerDependenciesMeta    → Marks specific peer deps as optional. 🏷️
├── optionalDependencies    → Nice to have. Works fine without it. 🤷
└── bundledDependencies     → Ships physically inside your package. 📁

npm install save flags:

npm install <pkg>              → dependencies (default, same as --save)
npm install <pkg> --save       → dependencies  (-S)
npm install <pkg> --save-dev   → devDependencies  (-D)
npm install <pkg> --save-optional → optionalDependencies  (-O)
npm install <pkg> --save-peer  → peerDependencies  (npm v7+)
npm install <pkg> --save-bundle → bundledDependencies  (-B)
npm install <pkg> --save-exact  → exact version pin, any category  (-E)
npm install <pkg> --no-save    → installs but does NOT save anywhere

Why This Actually Matters (Real Impact)

1. Smaller production builds

If your dependencies list contains testing libraries, linters, or build tools, your deployment gets unnecessarily heavy. A slim production node_modules loads faster and reduces attack surface.

2. No version conflicts in libraries

Wrong use of dependencies instead of peerDependencies in a library means two versions of React might end up in the same project. That causes hooks to break and warnings to fire — and debugging it is a nightmare.

3. Cleaner CI/CD pipelines

When CI knows which packages are for production and which are for dev, it can run optimized installs. npm ci --production in a deploy step skips all dev tools, saving time.

4. Better collaboration

When a new developer clones your project and runs npm install, they get everything they need — no more, no less — because the categories are correct.

Common Mistakes Developers Make

❌ Installing everything under `dependencies`

This is the most common mistake. Developers just run npm install package-name and move on, without thinking about whether it is a dev or runtime package.

Fix: Before installing, ask yourself: "Does this package need to exist when my app is running for users?" If yes → dependencies. If no → devDependencies.

❌ Using `dependencies` instead of `peerDependencies` in a library

If you are building a React component library and you add React to your dependencies, every project that installs your library might end up with two React instances. Two React instances = broken hooks and lots of confusion.

Fix: Always use peerDependencies for shared host packages when building libraries or plugins.

❌ Ignoring `optionalDependencies` error handling

If a package is optional, your code must handle the case where it does not exist. Many developers declare something as optional but then require() it without a try-catch, causing crashes.

// Bad
const fsevents = require('fsevents');

// Good
let fsevents;
try {
  fsevents = require('fsevents');
} catch {
  // Not available, continue without it
}

❌ Confusing `peerDependencies` with `devDependencies`

When writing a library, you still need React locally to build and test. So you add it to both devDependencies (for local dev) and peerDependencies (to declare what the host needs). Many developers only add it to one — and then wonder why their build fails or why users get version conflicts.

Do's & Don'ts

Do ✅	Don't ❌
Use `-D` for linters, test runners, bundlers	Don't ship ESLint or Jest to production
Use `peerDependencies` in npm libraries	Don't bundle React inside your component library
Handle missing optionalDependencies in code	Don't assume optional packages always install
Audit your `dependencies` before deploying	Don't just run `npm install x` blindly every time
Keep `bundledDependencies` for rare edge cases	Don't use it as a lazy substitute for proper publishing

Conclusion

Understanding dependency types in npm is one of those small things that makes a huge difference as your projects grow. 🚀

The short version:

package.json fields:

dependencies → Your app needs this at runtime. Always.
devDependencies → Only needed while you are coding. Never ships.
peerDependencies → For library authors. Let the host project provide it.
peerDependenciesMeta → Marks a peer dep as optional to silence warnings.
optionalDependencies → Nice to have. Handle gracefully if missing.
bundledDependencies → Rare. Packages shipped inside your package.

npm install flags:

--save / -S → Saves to dependencies (default since npm v5).
--save-dev / -D → Saves to devDependencies.
--save-optional / -O → Saves to optionalDependencies.
--save-peer → Saves to peerDependencies (npm v7+).
--save-bundle / -B → Saves to bundledDependencies.
--save-exact / -E → Pins exact version. Combines with any flag.
--no-save → Installs without touching package.json.

Getting this right keeps your production builds lean, your libraries conflict-free, and your package.json clean and professional.

If you found this helpful, share it with a teammate who is still dumping everything into dependencies 😊 — it might save them a frustrating debug session.

For more posts like this, head over to hamidrazadev.com where I write about frontend development, tools, and real-world developer problems.

VS Code 1.126: Track AI Costs, Run Multiple Chats, and Browse Code Safely

Muhammad Hamid Raza — Thu, 25 Jun 2026 07:39:45 +0000

You open a new project someone sent you. VS Code immediately interrupts you with a giant trust dialog before you can even look at the code. You click trust, realize you maybe shouldn't have, and now you're quietly hoping nothing weird runs. Sound familiar? 😅

VS Code 1.126 just landed on June 24, 2026, and it brings some genuinely useful upgrades — not just polish for the sake of polish, but real quality-of-life wins. We're talking AI cost transparency, running multiple agent chats side by side, and a smarter way to handle untrusted folders.

Let's walk through what's new and why it actually matters for your daily workflow.

What Is VS Code 1.126?

VS Code 1.126 is the latest monthly release of Visual Studio Code — Microsoft's wildly popular, free, open-source code editor. Every month, the team ships a new version with improvements ranging from subtle UI tweaks to major feature drops.

This release focuses heavily on Copilot chat and agent workflows, making AI assistance in VS Code more manageable, more readable, and less of a mystery when it comes to cost. It also quietly improves how you handle folders you don't fully trust yet.

If you use VS Code daily (and let's be honest, most of us do 👀), there's something in here for you.

Why This Release Matters

AI tools inside editors are no longer a novelty — they're becoming part of the actual development loop. But with that power comes a new kind of headache: you don't always know how much your AI interactions are costing you, or how to manage multiple threads of work at once.

This release tackles both of those problems head-on. It also quietly fixes one of those small-but-annoying security UX issues that has bugged developers for years. Whether you're a solo developer, part of a team, or just starting out, these changes make VS Code feel sharper and more intentional.

New Features and What They Actually Do

💰 Session-Level Cost Information

This is a big one for anyone using Copilot with credit-based plans.

Previously, you could only see the cost of an individual chat turn. Now, VS Code shows you the total cost for an entire chat session — not just one message, but the whole conversation combined. A session-level info popover also shows context window token usage across the whole session.

Why this matters: Imagine you're debugging a tricky async issue and you've sent 30 messages back and forth. Before this, you'd have no idea how many credits that conversation consumed until you checked your billing dashboard. Now, the information is right there in the chat UI.

It's like finally getting a running total at the grocery store instead of being surprised at checkout.

🧠 Unified Model Customization Picker

VS Code used to give you two separate dropdowns to configure a language model — one for context size and another for reasoning (thinking) effort. That was fine, but switching between them felt unnecessarily scattered.

Now, both settings live inside a single model customization picker. One place, two controls, done.

The model hover tooltip also got a cleanup. It now shows a concise one-word descriptor of the model's capabilities (instead of a wall of text), plus deep link buttons that take you directly to the settings you need.

Why this matters: When you're mid-task and want to quickly switch a model to "think harder" or reduce context size to save credits, the fewer clicks the better. This makes model tuning feel lighter.

🪟 Multiple Chats in One Agent Session

The Agents window (still in Preview) just got a significant upgrade.

Before, you could only have one chat running inside an agent host session. Now you can open multiple chats side by side within the same session. These chats share the same working context, which means:

Start a chat implementing a new feature
While it's working, open a second chat in the same session to write tests or review changes
Both run at the same time
Each chat keeps its own separate conversation thread

You can rename each chat tab so you don't lose track of what's what. And if you close VS Code and come back later, all your chats are persisted and restored — not just the first one.

Why this matters: This is genuinely useful for complex, multi-step work. It's like having two terminals open side by side, except for your AI conversations. No more "wait, where was that other chat I had about the database schema?"

💬 Agentic Code Feedback with Comments

If you use the Agents window for code review workflows, this one is for you.

Comments you leave on generated code are now stored on the agent host — not locally in your browser session. This means:

The agent can read and respond to your comments using server-side tools
Comments persist even if you disconnect the client
The agent itself can add inline comments using the addComment tool

When you run a review skill like /code-review, the agent reviews your code and drops inline comments that you can accept or delete before sending them back to the agent to address. Pull request review comments work the same way — the agent can request permission to view PR comments and then address them.

Why this matters: This closes the loop between you and the agent during reviews. Instead of copy-pasting feedback, you're annotating directly and the agent picks it up.

🔒 Safer Folder Browsing with Restricted Mode

This is the one that fixes that annoying trust dialog problem.

Previously, when you opened a new or unfamiliar folder in VS Code, it immediately hit you with a dialog asking whether you trust the folder — before you could even look at the code. Rushing past that dialog and clicking "Yes" without thinking was easy, and trusting code you haven't reviewed yet is a real security risk.

Now, new folders open in Restricted Mode by default. You get a simple banner at the top letting you know you're in safe-browsing mode. You can explore the files, read the code, and when you're ready and confident, you click to trust the folder.

No forced interruption. No accidentally trusting something sketchy before you've looked at it.

The security.workspace.trust.startupPrompt setting defaults to never now instead of once. If you want the old prompt-on-first-open behavior back, set it to once in your settings.

Additionally, the Trust Parent button was removed from the Workspace Trust editor. It looked nearly identical to the regular Trust button but trusted the entire parent folder instead of just the current one — which was easy to click by mistake. You can still trust a parent folder manually by adding it to the Trusted Folders list.

📰 New VS Code Blog Landing Page

Small but worth mentioning: the VS Code website now has a proper blog landing page instead of dropping you directly on the latest post. Previous posts were easy to miss before this. Now you can see recent posts at a glance and browse the full archive.

The documentation table of contents also got restructured — all agent docs are grouped under "Agents," code editing and config docs are under "Editor," and language/extension docs now live in their own dedicated sections instead of being scattered individually.

Quick Comparison: Before vs After

Feature	Before 1.126	After 1.126
AI cost visibility	Per-turn only	Full session total
Model configuration	Two separate dropdowns	Single unified picker
Agent chats per session	One at a time	Multiple side by side
Opening new folders	Trust dialog immediately	Restricted Mode first
Trust Parent button	Present (and easy to misclick)	Removed
Code review comments	Local to client session	Stored on agent host

Best Tips for Getting the Most Out of VS Code 1.126

✅ Do check the session cost popover regularly. If you're on a credit plan, keeping an eye on which sessions consume the most tokens helps you stay within budget.

✅ Do use multiple chats for parallel workflows. Keep one chat focused on implementation and another on testing or documentation. Rename the tabs so you know what's what at a glance.

✅ Do let Restricted Mode do its job. When you open an unfamiliar repo, take a moment to actually read through the code before clicking Trust. That's the whole point of the feature.

✅ Do try the /code-review skill in the Agents window. If you haven't used agent-driven code review yet, the new comment tools make it significantly more usable.

❌ Don't ignore the session cost info. It's easy to dismiss it, but if you're on a team plan or personal credit budget, it's genuinely useful context.

❌ Don't set startupPrompt back to once out of habit. The new Restricted Mode default is actually better. Give it a week before reverting.

Common Mistakes to Watch Out For

Thinking multiple chats means unlimited context. Multiple chats in a session share the same working context, which is powerful — but it doesn't mean the model has infinite memory. Heavy sessions still consume tokens and credits.

Forgetting to rename chat tabs. You open three chats, they all say "Chat 1," "Chat 2," "Chat 3," and twenty minutes later you have no idea which one has the database conversation. Rename them immediately. Double-click the tab, type something useful.

Assuming Restricted Mode means no functionality. You can still read files, search code, and navigate the project in Restricted Mode. Extensions and task runners that need to run code are restricted, which is exactly the point. You're not locked out — you're just safe-browsing.

Looking for the Trust Parent button and panicking. It's gone on purpose. Add a parent folder path manually to the Trusted Folders list if you genuinely need to trust it. That extra step is intentional so you don't do it by accident.

Wrapping Up 🚀

VS Code 1.126 isn't the flashiest release of the year, but it's a thoughtful one. The team took three real pain points — AI cost opacity, fragmented agent workflows, and the trust-before-you-look security UX — and made practical improvements to all three.

Session cost tracking, unified model controls, multi-chat sessions, and safer restricted-mode browsing are all features you'll appreciate quietly in your daily work. The kind of release that doesn't make headlines but makes your day smoother.

Update your VS Code now (or go to Help → Check for Updates if it hasn't rolled out to you yet), and try opening your next unfamiliar repo in Restricted Mode like the responsible developer you are. 😊

Want more developer content like this? Head over to hamidrazadev.com for more posts, tools, and updates from the dev world. If this post saved you some time or cleared something up, share it with a fellow dev — it genuinely helps. 🙌

GET, POST, and Friends: A Simple Guide to HTTP Request Methods (And When to Use Each)

Muhammad Hamid Raza — Sun, 21 Jun 2026 08:48:30 +0000

If you've ever opened your browser's Network tab and seen a bunch of requests labeled GET, POST, PUT, DELETE… and quietly wondered "wait, what's actually the difference?" — you're not alone. 😊

Most developers learn to use these methods way before they actually understand why one is chosen over another. You copy a tutorial, the API call works, and you move on. Until one day you accidentally send sensitive data through a GET request, or your "update" endpoint behaves weird because it's not idempotent — and suddenly this stuff matters a lot.

So let's slow down and actually understand HTTP request methods, what they're for, and how to pick the right one. No jargon overload, just clear explanations. 🚀

What Are HTTP Request Methods?

Every time your browser or app talks to a server, it sends an HTTP request. That request needs to tell the server what kind of action it wants to perform. That's exactly what the "method" (sometimes called the "verb") does.

Think of it like walking into a library. You might be there to:

Look at a book (just reading, nothing changes)
Add a new book to the shelf
Replace an old book with a new edition
Remove a book completely

HTTP methods are the formal way of telling the server which of these actions you intend to do. The server then responds based on that intent.

In code, a request method usually looks like this:

GET /users/42 HTTP/1.1
Host: example.com

That GET at the start? That's the method. Simple as that.

Why This Topic Matters

Here's the thing — picking the wrong HTTP method isn't just "technically incorrect." It causes real problems:

Search engines and browsers may cache GET requests, so if you use GET to delete something, a bot crawling your site could accidentally trigger it. (Yes, this has actually happened to real companies.)
Some methods are expected to be idempotent (calling them multiple times gives the same result), and breaking that expectation can cause bugs that are painful to track down.
REST APIs are built around these methods. If you're building or consuming an API, understanding methods makes the whole API design make sense instantly instead of feeling like memorized magic.

Once this clicks, reading any API documentation becomes a lot less intimidating. 💡

The Main HTTP Methods and Their Use Cases

Let's go through the ones you'll actually use day to day.

1. GET — Fetching data
Used to retrieve information without changing anything on the server.
Example: Loading a user's profile page, fetching a list of products, or calling GET /posts/10 to read a blog post.

2. POST — Creating something new
Used to send data to the server, usually to create a new resource.
Example: Submitting a signup form, creating a new blog post, or sending a comment.

3. PUT — Replacing a resource completely
Used to update a resource by replacing it entirely with the new data you send.
Example: Updating a user's full profile where you send the entire object (name, email, bio — everything), not just one field.

4. PATCH — Updating part of a resource
Used when you only want to change a specific field, not the whole thing.
Example: Updating just a user's email address without touching their name or bio.

5. DELETE — Removing a resource
Used to delete something from the server.
Example: DELETE /posts/10 to remove a blog post permanently.

6. HEAD — Like GET, but without the body
Used to check if a resource exists or get its headers (like file size or last-modified date) without downloading the full content.
Example: Checking if a large file still exists before downloading it.

7. OPTIONS — Asking what's allowed
Used to find out which methods and headers are supported for a particular endpoint. Browsers often send this automatically as a "preflight" request before certain cross-origin requests (CORS).

Each of these exists because real-world apps need different kinds of actions — reading, creating, replacing, partially updating, deleting, and checking. Once you see them as "actions," not random labels, they stop feeling abstract.

GET vs POST: The Comparison Everyone Actually Needs

These two get confused the most, so here's a quick side-by-side:

	GET	POST
Purpose	Retrieve data	Send/create data
Data location	Sent in the URL (query params)	Sent in the request body
Visible in URL?	Yes	No
Cacheable?	Yes, by default	Generally no
Safe for sensitive data?	No — avoid passwords, tokens, etc.	Safer, since it's not in the URL
Idempotent?	Yes (calling it repeatedly is safe)	No (each call may create a new resource)

A simple rule of thumb: if you're just looking at something, use GET. If you're changing something, use POST, PUT, PATCH, or DELETE depending on what kind of change it is.

Best Tips for Using HTTP Methods Correctly

✅ Use GET only for reading. Never use it to trigger actions like deleting or updating data.
✅ Match PUT and PATCH to what you're actually sending. Full object replacement → PUT. Partial update → PATCH.
✅ Don't put sensitive data in a GET URL. URLs get logged in browser history, server logs, and proxies.
✅ Return the right status code with each method. For example, 201 Created after a successful POST, 204 No Content after a successful DELETE.
✅ Keep DELETE requests intentional. Add confirmation steps in your UI so a DELETE call doesn't fire accidentally.

Common Mistakes People Make

1. Using GET to perform actions
Some beginners build endpoints like GET /deleteUser/5 because it's "easier to test in the browser." This is risky — browsers, crawlers, or cached links could trigger it unintentionally.

2. Treating PUT and PATCH as interchangeable
They look similar, but PUT expects the full resource, while PATCH expects only the changed fields. Mixing them up can silently wipe out data you didn't mean to touch.

3. Forgetting that POST isn't idempotent
If a POST request fails and your app retries it automatically without protection (like an idempotency key), you could end up creating duplicate records — duplicate orders, duplicate sign-ups, and so on.

4. Ignoring OPTIONS and CORS issues
When working with frontend apps calling APIs on a different domain, the browser sends an OPTIONS request first. If your backend doesn't handle it properly, your "perfectly working" POST request will fail — and it's confusing if you don't know OPTIONS exists.

Wrapping Up

HTTP request methods aren't just labels — they're a shared language that tells servers exactly what kind of action you intend to perform. Once you understand the role of GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS, API documentation stops feeling like a puzzle and starts feeling like a map you already know how to read.

If this helped clear things up, you'll find more practical, no-fluff developer guides like this over at hamidrazadev.com. Feel free to share this with a fellow dev who's still mixing up PUT and PATCH 😊, and drop a comment if you'd like a deeper dive into any of these methods!

VS Code 1.125 Is Here: A Smarter Browser, Better Extension Updates, and More Copilot Control 🚀

Muhammad Hamid Raza — Sat, 20 Jun 2026 07:48:24 +0000

Ever updated VS Code, opened a dozen tabs to figure out "wait, what actually changed?", and given up halfway through? Yeah, me too.

VS Code 1.125 landed on June 17, 2026, and this time the changelog is actually worth your coffee break. There's a browser built right into your editor that can now search the web and reach into remote machines, you finally get to decide when your extensions update instead of being surprised mid-debug session, and IT admins get a much easier way to roll out Copilot settings across a whole company.

Let's break down what's new, why it matters, and how to actually use it. 👀

What Is VS Code 1.125?

If you're new here: Visual Studio Code is the free code editor made by Microsoft that most developers use every single day. Think of it like your workshop — it's where you write code, fix bugs, and build whatever you're working on.

Every few weeks, the VS Code team ships an update. Sometimes it's small polish, sometimes it's a feature that changes your daily workflow. Version 1.125 is one of the bigger ones, with real improvements to the agent experience, the language model picker, the integrated browser, and how extensions update themselves.

Think of it like your phone getting a software update — except instead of just fixing battery drain, it sometimes hands you a whole new tool you didn't know you needed.

Why This Update Matters

A code editor isn't just where you type. It's where you search docs, test APIs, debug remote servers, manage extensions, and (if you're on a team) follow company policy without it getting in your way.

1.125 touches all of that:

You can now search the web directly inside VS Code's browser instead of alt-tabbing to Chrome fifty times a day.
You get control over when extensions update, so a risky update doesn't drop in the middle of a live demo.
Teams using Copilot get centralized policy management, which makes life easier for admins and more predictable for developers.

None of this is flashy AI magic. It's the kind of "small friction removed" update that quietly makes your day smoother — and those add up.

Benefits with Real-Life Examples 💡

1. Web search right in the integrated browser

Setting: workbench.browser.searchEngine

You can now type a query straight into the integrated browser's address bar, and it searches using your configured search engine — just like a normal browser tab.

Real-life example: You're deep in a function, need to quickly check a Stack Overflow answer or MDN doc, and instead of switching windows and losing your train of thought, you just search right there in VS Code. Small thing, but it keeps you "in the zone."

2. Browse over remote connections (Preview)

Setting: workbench.browser.enableRemoteProxy

When you're working in a remote workspace (like a dev container or remote SSH server), the integrated browser can now proxy your web traffic through that remote connection. That means you can securely reach ports or internal services that are only visible from the remote machine.

Real-life example: You're running a local dashboard on a remote dev server at port 5000. Normally that's invisible to your laptop's browser. Now, with this preview setting on, VS Code can reach it directly. It's still labeled "preview," so expect a few rough edges — but it solves a genuinely annoying problem.

3. Better port handling for agents

If you've forwarded a port in a remote workspace, agents previously could fumble trying to open the browser because the port number didn't match. Now, when an agent requests a forwarded port, VS Code rewrites the URL automatically and lets the agent know. Less confusion, fewer "why isn't this loading" moments.

4. Install model providers straight from the Language Models editor

Extensions can bring their own AI model providers beyond the usual Bring Your Own Key (BYOK) setup. Before, you had to already know the right tag to search for in the Extensions view (language-models — now you know 😄).

Now there's an Install Model Providers button right in the Language Models editor. Click it, and it opens the Extensions view already filtered to relevant extensions. Once installed, the new models just show up in your model picker alongside everything else.

Real-life example: You hear about a new model provider extension from a colleague but don't remember the exact search term. Now you don't need to — the button does the filtering for you.

5. Configurable extension auto-update delay

Setting: extensions.autoUpdateDelay

This builds on the delayed auto-update feature from the previous release. You can now set, in hours, how long VS Code waits before it installs an extension update. By default, it's two hours.

Real-life example: An extension you rely on pushes a buggy update. With a delay configured, you (or your team) have a window to spot the problem before it lands on every machine. It's a small safety net that costs nothing to set up.

6. Simplified auto-update setting

Setting: extensions.autoUpdate

The setting is now just on or off — no more juggling true, false, onlyEnabledExtensions, and delayed. Existing values migrate automatically. One useful behavior to know: when auto-update is on, only enabled extensions get updated. Disabled ones update the next time you turn them back on.

7. Track your Copilot additional spend

The Copilot status dashboard now shows what percentage of your additional spend budget you've used. If you're on a usage-based plan, you can glance at this before you accidentally blow past your limit.

Real-life example: You're mid-sprint, leaning on Copilot heavily, and instead of getting surprised by a bill, you check the dashboard and see you're at 80% of your extra budget. Now you can pace yourself (or ask finance for more budget, no judgment).

8. Native MDM delivery for managed Copilot settings

For teams: admins can now push Copilot policies through native device management (MDM) on Windows and macOS, not just through the account-based settings file. This means policy can be enforced at the device level, without needing every developer to sign in first.

Real-life example: A company wants to disable a certain Copilot feature org-wide for compliance reasons. IT can now push that through the same MDM tooling they already use for everything else — no extra sign-in step required from each developer, and the setting shows up as policy-enforced and locked in VS Code.

9. Language Server Protocol updated to 3.18

If you build language servers, you can now use protocol version 3.18, with vscode-languageclient@10.0.0 and vscode-languageserver@10.0.0 available as the matching client and server packages. Check the changelog for the full list of additions and breaking changes before upgrading.

Auto-Update: Before vs After 1.125

	Before 1.125	After 1.125
Update timing control	Limited delay options, confusing setting values	Clean `on`/`off` toggle plus a configurable delay in hours
Disabled extensions	Could still get updated in some cases	Only update when you re-enable them
Admin policy control	Account-based settings file only	Account-based file or native MDM on Windows/macOS

This isn't a dramatic before-and-after — it's VS Code quietly removing rough edges. But if you've ever been bitten by a surprise extension update, you'll appreciate it.

Best Tips for Using 1.125

Set a sensible auto-update delay. Two hours is the default, but if you work on a critical project, consider bumping it up so you have time to notice problems before they hit your machine.
Try the integrated browser's web search before reaching for Chrome. It's a tiny habit change that keeps you focused.
If you're on a remote workspace often, turn on workbench.browser.enableRemoteProxy and see if it saves you from manual port-forwarding gymnastics. Remember it's a preview feature, so report bugs if you hit any.
Check your Copilot spend dashboard regularly if you're on a usage-based plan — don't wait for the bill to surprise you.
If you manage a team, look into the new MDM delivery option for Copilot policies. It can simplify your rollout, especially if you already use device management tools.

Common Mistakes to Avoid

Assuming the remote browser proxy is production-ready. It's explicitly marked as a preview feature. Don't build a critical workflow around it yet — test it, expect occasional bugs, and report issues if you find them.

Forgetting that disabled extensions don't auto-update. If you disable an extension to "deal with it later" and forget about it, it'll be stuck on an old version until you re-enable it. Not a bug — just something to remember.

Ignoring the LSP version bump if you maintain a language server. Jumping to vscode-languageclient@10.0.0 without checking the changelog could introduce breaking changes you didn't expect. Read the notes first, then upgrade.

Mixing up the auto-update setting values after migration. If you had a custom value like onlyEnabledExtensions before, it gets migrated automatically — but it's worth double-checking your settings.json after updating, just so there are no surprises.

Wrapping Up

VS Code 1.125 isn't a flashy, headline-grabbing release — it's a "the little things finally got fixed" release. A browser that searches the web and reaches remote ports, extension updates you actually control, and Copilot policies that are easier for teams to manage. Put together, it's a smoother day-to-day experience for solo developers and teams alike.

If this rundown helped you understand what's new without digging through the full changelog yourself, that's exactly what it's here for. 😊

Want more developer-friendly breakdowns like this one? Check out more posts at hamidrazadev.com, and if this saved you some time, share it with a teammate who's still wondering why their extensions keep updating at the worst possible moment. Got thoughts on the new integrated browser features? Drop a comment — I'd love to hear how you're using them. 🔧

Postman Explained: How to Use It, Set Up Environments, and Structure a Real Project 🚀

Muhammad Hamid Raza — Sat, 20 Jun 2026 07:28:29 +0000

If you've ever tested an API by pasting a URL into your browser and praying it works... we need to talk. 😅

That used to be me too. Then I found Postman, and testing APIs stopped feeling like guesswork. No more switching between five terminal tabs just to check if your login endpoint actually returns a token.

Here's the real question though: do you actually know how to set up Postman the right way — environments, variables, and a clean project structure — or are you still copy-pasting the same base URL into every single request? 👀

By the end of this post, you'll know exactly how to use Postman properly, how environments work, and how to structure a project the way real teams do it at work. Let's get into it.

What Is Postman?

Postman is a tool that lets you send requests to an API and see what comes back — without writing a single line of code.

Think of an API like a restaurant kitchen. You (the customer) don't walk into the kitchen and cook your own food. You give your order to a waiter (the API), and the kitchen sends back your meal. Postman is like a practice menu where you can place test orders anytime, see exactly what the kitchen sends back, and check if it's correct — all before your actual app ever talks to that kitchen.

In technical terms: Postman lets you send HTTP requests (GET, POST, PUT, DELETE, and more) to any API endpoint, attach headers, send data in the body, and inspect the response — status code, JSON data, response time, all of it.

It's used by backend developers to test their own APIs, frontend developers to understand what data they'll receive, and QA engineers to verify that APIs behave correctly.

Why Postman Matters

Here's the thing — before you connect your frontend to a backend, you need to know the backend actually works. Postman lets you confirm that before writing a single line of fetch or axios code.

It also saves you from one of the most annoying debugging situations: not knowing if a bug is in your frontend code or your backend API. With Postman, you test the API directly. If Postman gets a clean response and your app still breaks, you know exactly where to look.

For teams, it goes further. Postman becomes a shared source of truth. Instead of one developer explaining an API over Slack message by message, they just share a Postman collection, and everyone sees the exact same requests, headers, and expected responses.

Benefits with Real-Life Examples

Test APIs without writing frontend code — Building a login API? Test it in Postman first. Send the email and password, check if you get a token back, before touching your React form at all.
Reuse requests instead of rewriting them — Save a "Get User Profile" request once. Run it 50 times while you tweak your backend, instead of retyping the URL and headers every time.
Catch bugs early — If your API returns a 500 error in Postman, you know the problem is on the backend, not in your UI code. That alone can save hours of confused debugging.
Share your API with teammates instantly — Export a collection, send the link, and your teammate has the exact same setup in seconds — no "wait, what URL did you use?" conversations.
Automate testing — Postman can automatically check things like "did this return a 200 status?" or "does this response include a user ID?" every time you run a request.

How to Use Postman: Requests and Environments

Let's go through the actual workflow, step by step.

1. Sending Your First Request

Open Postman, click New Request, choose a method (GET, POST, etc.), paste in your API URL, and hit Send. That's it. You'll see the response body, status code, and timing right below.

2. Why You Need Environments

Here's a mistake almost every beginner makes: hardcoding the base URL in every single request.

https://api.myapp.com/users
https://api.myapp.com/products
https://api.myapp.com/orders

Now imagine your backend moves to a staging server, or you need to test locally. You'd have to manually update the URL in every request. That's painful and error-prone.

Environments fix this. An environment is just a named set of variables — for example, Development, Staging, and Production — each holding different values for the same variable names.

3. Creating an Environment

In Postman, click the Environments tab on the left sidebar, then Create Environment. Give it a name like Development, and add a variable:

Variable	Initial Value
`base_url`	`http://localhost:5000/api`

Create a second environment called Production with the same variable name but a different value:

Variable	Initial Value
`base_url`	`https://api.myapp.com`

Now, instead of writing the full URL in every request, you write:

{{base_url}}/users
{{base_url}}/products

Switch the active environment from the dropdown in the top-right corner, and every request instantly points to the correct server. No editing, no retyping. 💡

4. Variable Scopes (Quick but Important)

Postman has a few levels of variables, and they matter more than people realize:

Global variables — Available everywhere, across all collections.
Collection variables — Available only within one collection.
Environment variables — Tied to the active environment (Dev, Staging, Production).
Local variables — Exist only for a single request or script run.

If the same variable name exists in multiple scopes, Postman uses the most specific one. Knowing this saves you a lot of "why isn't my variable updating" confusion.

Setting Up a Real Project: Industry-Style Postman Structure

This is the part most tutorials skip. Here's how a real backend team typically structures Postman for an actual project — let's use a simple e-commerce API as an example.

Step 1: Create a Workspace

A Workspace is where your whole team works from. Create one and name it after the project, like MyShop API.

Step 2: Organize the Collection by Resource

Inside one collection, create folders by feature, not by HTTP method:

MyShop API (Collection)
├── Auth
│   ├── POST Register
│   ├── POST Login
│   └── POST Refresh Token
├── Users
│   ├── GET Get Profile
│   └── PUT Update Profile
├── Products
│   ├── GET List Products
│   ├── GET Get Product by ID
│   ├── POST Create Product (admin)
│   └── DELETE Delete Product (admin)
└── Orders
    ├── POST Create Order
    └── GET Get My Orders

This mirrors how the backend code itself is usually organized (controllers/routes by feature), so anyone on the team can find what they need instantly.

Step 3: Set Authorization at the Collection Level

Instead of adding your auth token to every single request, set it once at the collection root: Authorization tab → Bearer Token → {{access_token}}. Then in each request's Auth tab, choose Inherit auth from parent. One token, used everywhere.

Step 4: Auto-Save Tokens with Test Scripts

This is where Postman becomes genuinely powerful. On your Login request, open the Tests tab and add:

const response = pm.response.json();

if (response.token) {
  pm.environment.set("access_token", response.token);
}

pm.test("Status code is 200", function () {
  pm.response.to.have.status(200);
});

Now, every time you log in through Postman, your token is automatically saved into the environment — and every other request that uses {{access_token}} just works. No manual copy-pasting tokens between requests.

Step 5: Chain Requests Together

Same idea applies to IDs. After creating a product, save its ID:

const response = pm.response.json();
pm.environment.set("product_id", response.id);

Now your "Get Product by ID" request can use {{product_id}} directly. This is exactly how real test flows are built — one request feeds the next.

Step 6: Run the Whole Flow Automatically

Use the Collection Runner (or Newman, Postman's command-line tool) to run every request in order automatically, with all the test assertions checked each time. Teams plug Newman into CI/CD pipelines so the API gets tested automatically on every code push — before a bug ever reaches production.

Manual API Testing vs Using Postman

Manual Testing (curl / browser)	Using Postman
Retype the same request every time	Save and reuse requests instantly
Hard to manage tokens and headers	Auto-store tokens with scripts
No easy way to switch dev/prod URLs	One-click environment switching
Hard to share with teammates	Share collections in seconds
No built-in way to verify responses	Built-in test assertions

Manual testing with curl still has its place — it's fast for a single quick check. But for anything beyond a one-off request, Postman saves real time.

Best Tips / Do's & Don'ts

Do:

Use environments from day one, even on solo projects. Future-you will thank present-you.
Name requests clearly: POST Auth - Login, not Request 1.
Write at least one test per request, even just a status code check.
Keep secrets (API keys, tokens) inside environment variables, not hardcoded in the request.

Don't:

Don't hardcode URLs or tokens directly into requests.
Don't dump every request into one giant unorganized list — use folders.
Don't share a collection with real production secrets baked into it. Use placeholder values and let each teammate fill in their own environment.

Common Mistakes People Make

Hardcoding the base URL everywhere. This happens because it feels faster at first. But the moment you need to switch servers, you're editing dozens of requests instead of one variable.

Forgetting which environment is active. A classic one — testing against Production by accident because you forgot to switch the dropdown. Always glance at the top-right corner before sending a request to anything sensitive.

Not organizing collections with folders. Early on, a flat list of 10 requests feels fine. At 80 requests, it's chaos. Folder by feature from the start, even if your project is small right now.

Skipping tests because "it's just for testing." Even one simple pm.response.to.have.status(200) check catches more bugs than you'd expect, especially when you come back to a project after a few weeks away.

Wrapping Up

Postman turns API testing from a guessing game into something organized and repeatable. Environments let you switch between local, staging, and production with one click. A clean folder structure keeps your collection readable as your project grows. And test scripts let requests pass data to each other automatically, the same way real backend teams set things up.

Start small — create one environment, organize your requests into a few folders, and add one test script. You'll feel the difference immediately.

If this helped you understand Postman a little better, you'll find more practical, no-fluff developer guides over at hamidrazadev.com. Feel free to share this with a teammate who's still pasting raw URLs into the browser, and drop a comment if you've got a Postman tip of your own — always happy to learn one more trick. ✅

HTTP Status Codes Explained: The Complete Guide Every Developer Needs 🚀

Muhammad Hamid Raza — Fri, 19 Jun 2026 11:47:44 +0000

You open DevTools. You see a request fail. And there it is: a three-digit number staring back at you like it owes you money.

404. 500. 403. 301.

If you've ever stared at one of these and thought "okay... but what do I actually do now?" — you're not alone. Every developer, from total beginners to people who've shipped production apps for years, has Googled a status code at 2 AM.

Here's the good news: HTTP status codes aren't random. They're a simple, organized language your server uses to tell your browser (or your app, or your API client) exactly what happened. Once you understand the pattern, you'll never feel lost again. 💡

Let's break it down properly.

What Are HTTP Status Codes?

Every time your browser asks a server for something — a webpage, an image, an API response — the server replies with two things: the actual content (if any), and a status code.

Think of it like ordering food at a counter. You ask for a burger. The person behind the counter can say:

"Here you go!" ✅ (your order worked)
"We're out of buns, give us a sec" (something temporary happened)
"That's not on our menu" (you asked for something that doesn't exist)
"Our kitchen caught fire" (it's not your fault — something broke on their end)

HTTP status codes are exactly that, but for the web. They're three-digit numbers, and the first digit tells you the category:

1xx – Informational: "Hold on, I'm working on it"
2xx – Success: "Here's your stuff, all good"
3xx – Redirection: "What you want is actually over here"
4xx – Client Error: "You (the request) did something wrong"
5xx – Server Error: "I (the server) messed up"

That's it. That's the whole system. Everything else is just detail within those five buckets.

Why This Topic Matters

You can't debug what you don't understand. Status codes are usually the first clue you get when something breaks — before you even open a single line of code.

A 404 tells you to check your URL or routing. A 401 tells you it's an auth problem, not a server problem. A 500 tells you to look at your backend logs, not your frontend fetch call.

Knowing status codes well saves you time. Instead of randomly poking at your code, you immediately know where to look. That's the difference between a 5-minute fix and an hour of guessing. ⚡

It also matters for your career. Status codes come up in interviews, code reviews, API design discussions, and daily standups. Saying "the API returns a 422 when validation fails" instantly signals you know what you're talking about.

The Quick Reference Table

Here's a scannable list of the standard codes, grouped by class. Bookmark this section. 👀

1xx — Informational

Code	Name	Meaning
100	Continue	Server received the request headers; client should send the body
101	Switching Protocols	Server is switching protocols as requested (e.g., to WebSocket)
102	Processing	Server is still processing, response isn't ready yet
103	Early Hints	Server sends some headers early, before the final response

2xx — Success

Code	Name	Meaning
200	OK	The request succeeded
201	Created	A new resource was successfully created
202	Accepted	Request accepted, but processing isn't finished yet
204	No Content	Success, but there's nothing to send back
206	Partial Content	Server sent only part of the resource (used in streaming/downloads)

3xx — Redirection

Code	Name	Meaning
301	Moved Permanently	The resource has a new permanent URL
302	Found	Temporary redirect to a different URL
303	See Other	Redirect, typically after a form submission
304	Not Modified	The cached version is still valid, no need to re-download
307	Temporary Redirect	Like 302, but guarantees the method (GET/POST) stays the same
308	Permanent Redirect	Like 301, but guarantees the method stays the same

4xx — Client Error

Code	Name	Meaning
400	Bad Request	The request itself is malformed or invalid
401	Unauthorized	You're not authenticated — log in first
403	Forbidden	You're authenticated, but not allowed to access this
404	Not Found	The resource doesn't exist
405	Method Not Allowed	You used the wrong HTTP method (e.g., POST on a GET-only route)
408	Request Timeout	The server gave up waiting for the request
409	Conflict	The request conflicts with the current state (e.g., duplicate entry)
410	Gone	The resource existed once, but is permanently removed
413	Payload Too Large	You sent too much data
415	Unsupported Media Type	The format you sent isn't accepted
422	Unprocessable Entity	The request is well-formed, but the data fails validation
429	Too Many Requests	You're being rate-limited

5xx — Server Error

Code	Name	Meaning
500	Internal Server Error	Something broke on the server, and it's generic/unhandled
501	Not Implemented	The server doesn't support this functionality
502	Bad Gateway	A server acting as a proxy got an invalid response upstream
503	Service Unavailable	Server is overloaded or down for maintenance
504	Gateway Timeout	A proxy/gateway didn't get a response in time

There are a few more obscure ones (like 418 I'm a Teapot, which was originally an April Fools' joke in an RFC and is now sometimes used playfully), but the codes above cover the vast majority of what you'll see in real-world development.

Benefits of Understanding Status Codes

Faster debugging — A 403 tells you immediately it's a permissions issue, not a missing route. You skip straight to checking auth logic instead of guessing.
Better API design — When you build your own API, choosing the right code (like 201 instead of 200 after creating a resource) makes your API predictable and easier for other developers to consume.
Clearer communication with teammates — Saying "we're getting a 429 from their API" is faster and more precise than "it's just... not working."
Smarter error handling in code — Once you know the categories, you can write logic like "if status is in the 4xx range, show a user-facing error; if it's 5xx, retry or alert the team." This pattern shows up in almost every frontend app that talks to an API.
Confidence during interviews — Status codes are a common technical interview topic. Knowing the difference between 401 and 403, or 301 and 302, shows real hands-on experience.

Comparison: 4xx vs 5xx Errors

This distinction trips up a lot of beginners, so it's worth calling out clearly.

4xx (Client Error)

The problem is with the request.
Example: wrong URL, missing auth token, bad input data.
Fix: usually something the frontend or the API consumer needs to correct.

5xx (Server Error)

The problem is on the server's side.
Example: a crash in backend code, a database that's unreachable, a misconfigured server.
Fix: usually something the backend team needs to investigate in logs.

The simple rule: 4xx means "check your request," 5xx means "check the server." This one mental model alone will speed up a huge chunk of your debugging sessions.

Best Tips and Do's & Don'ts

✅ Do check the Network tab in DevTools before assuming your code is broken. The status code often tells you exactly where to look.

✅ Do use specific status codes in your own APIs (201 for creation, 204 for a successful delete with no body) instead of always returning 200.

✅ Do handle 4xx and 5xx differently in your error-handling logic. A 4xx might mean "show the user a message." A 5xx might mean "retry the request" or "alert the team."

❌ Don't treat every error the same way in your frontend code. A 401 should usually redirect to login. A 500 shouldn't.

❌ Don't ignore 429 Too Many Requests. If you're hitting rate limits, slamming the API harder won't help — you need backoff logic.

❌ Don't assume 404 always means "the page doesn't exist." Sometimes it's a typo in your route, a missing trailing slash, or a misconfigured server rule.

Common Mistakes People Make

Mixing up 401 and 403. Beginners often use these interchangeably. 401 means "I don't know who you are — please log in." 403 means "I know who you are, but you're not allowed in." Mixing them up confuses anyone debugging your API later.

Returning 200 for everything, even errors. Some APIs send a 200 OK even when something failed, with the actual error buried inside the JSON body. This breaks standard error-handling patterns and forces every consumer of your API to read documentation just to know if something worked. Stick to proper status codes — it saves everyone time.

Not handling redirects properly. Developers sometimes assume a 301 and 302 behave identically. They don't. A 301 tells browsers and search engines "update your bookmarks, this is permanent" — which affects caching and SEO. A 302 says "this is temporary, don't update anything permanently."

Panicking at any 4xx or 5xx without reading the code. Not all errors are equal. A 404 on an optional resource might be totally fine to ignore. A 500 on a critical checkout flow needs immediate attention. Context matters more than the fact that "something failed."

Wrapping Up

HTTP status codes aren't scary once you see the pattern: 1xx is "wait," 2xx is "success," 3xx is "look elsewhere," 4xx is "you made a mistake," and 5xx is "I made a mistake."

That's the whole mental model. Everything else — every specific code — is just a more detailed flavor of one of those five ideas.

Next time you see a status code pop up in your console, you won't panic. You'll know exactly where to start looking. ✅

If this helped clear things up, consider sharing it with another developer who's still Googling "what does 403 mean" at 1 AM. And if you want more practical, no-fluff developer content like this, you can find more posts at hamidrazadev.com. Drop a comment if you've got a status code horror story — we've all got one. 😊

NestJS: The Backend Framework That Makes Node.js Feel Grown-Up 🚀

Muhammad Hamid Raza — Wed, 17 Jun 2026 11:21:04 +0000

If you have ever tried to build a large Node.js backend and thought, "Why does this feel like I'm making it up as I go?" — you are not alone.

Express is powerful. Fastify is fast. But neither one tells you how to structure your project. You end up inventing your own patterns, copying folder structures from tutorials, and praying nothing breaks when the project grows.

That is exactly the problem NestJS was built to solve. And it is solving it really well.

So what is NestJS, why is everyone suddenly talking about it, and should you actually learn it? Let's find out.

What Is NestJS?

NestJS is a framework for building server-side applications using Node.js. It is written in TypeScript and uses a structured, opinionated architecture inspired by Angular.

Think of it this way:

Node.js is the engine.
Express is a car with no seats, no doors, and no steering wheel — powerful, but you have to build everything yourself.
NestJS is a fully assembled car. The seats, doors, engine, and GPS are already there. You just drive.

Under the hood, NestJS uses Express by default (and optionally Fastify). So you are not throwing away what you know — you are building on top of it with a proper structure.

NestJS uses TypeScript, decorators, modules, controllers, and services to organize your code in a clean, predictable way. If you have used Angular, this will feel very familiar. If you have not, it is still easy to pick up.

Why NestJS Is Getting So Much Attention

Backend development with Node.js has always had an awkward problem. Node.js gives you total freedom, and total freedom means total responsibility for every decision. File structure? Up to you. Dependency injection? Figure it out yourself. Modules? Sure, but how?

For small projects, this is fine. For production-grade apps with teams and deadlines? It becomes chaos.

NestJS fixes this by giving developers a clear, consistent way to build backends. It enforces good habits without being painful. And it does this while staying close to patterns that most JavaScript and TypeScript developers already understand.

Here is why developers are choosing it:

Teams can onboard faster because the folder structure is always familiar
TypeScript is a first-class citizen, not an afterthought
Testing is built into the framework, not bolted on
It works great for REST APIs, GraphQL, WebSockets, and microservices
The documentation is genuinely excellent

Benefits with Real-Life Examples

✅ Structured Architecture Out of the Box

You do not need to spend three hours deciding where to put your files. NestJS gives you modules, controllers, and services right away. A UsersModule with a UsersController and UsersService just makes sense — you can read it and know exactly what each piece does.

✅ TypeScript by Default

No setup, no config fights. You write TypeScript from day one. This means better autocomplete, fewer runtime surprises, and errors you catch before your users do.

✅ Built-In Dependency Injection

NestJS handles dependency injection automatically. You declare what a service needs, and NestJS provides it. No messy manual wiring. This also makes unit testing much cleaner because you can swap out dependencies easily.

✅ Great for REST, GraphQL, and Microservices

Whether you are building a REST API, a GraphQL server, or a message-queue-based microservice, NestJS supports all of it with first-party packages. You do not need to piece together five different libraries and hope they play nicely together.

✅ Powerful CLI

nest generate module users
nest generate controller users
nest generate service users

Three commands and your entire Users feature is scaffolded, connected, and ready for logic. This saves a meaningful amount of time on every project.

✅ Testing Is a First-Class Feature

NestJS generates test files automatically alongside your code. It integrates with Jest and provides utilities for mocking services, making unit and integration testing far less painful than it usually is in Node.js projects.

NestJS vs Plain Express: When Does It Actually Matter?

Situation	Plain Express	NestJS
Quick prototype or tiny API	✅ Perfect	Might be overkill
Medium to large production app	Gets messy fast	✅ Shines here
Team of 2+ developers	Coordination headaches	✅ Consistent structure
TypeScript-first project	Manual setup needed	✅ Built in
Microservices or event-driven	DIY everything	✅ First-party support
GraphQL	Third-party setup	✅ Official package

The honest answer: for small scripts and quick demos, Express is simpler. But the moment your app grows beyond a few routes, or when more than one developer is involved, NestJS becomes the smarter choice.

Core Concepts You Need to Know

You do not need to memorize everything at once. But these four building blocks are the heart of NestJS.

Modules

Modules are organizational units. Every NestJS app has at least one — the AppModule. You then create feature modules like UsersModule, AuthModule, and ProductsModule. Each module owns its own controllers and services.

Controllers

Controllers handle incoming HTTP requests and return responses. A UsersController handles routes like GET /users or POST /users. They are thin — they receive a request, pass it to a service, and return the result.

Services

Services contain the actual business logic. The controller talks to the service. The service talks to the database or external APIs. This separation keeps your code clean and testable.

Providers and Dependency Injection

Services are providers. NestJS injects them automatically where they are needed. If your UsersController needs the UsersService, you just declare it in the constructor and NestJS handles the rest.

Here is a quick example of what this looks like:

@Injectable()
export class UsersService {
  findAll() {
    return [{ id: 1, name: 'Hamid' }];
  }
}

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }
}

Clean. Readable. Predictable. 💡

Best Tips for Getting Started

Start with the official CLI. Install it globally and let it scaffold your project:

npm install -g @nestjs/cli
nest new my-project

Learn modules before anything else. The module system is the foundation of everything. Once it clicks, the rest makes sense quickly.

Use the official documentation. The NestJS docs are some of the best in the Node.js ecosystem. Do not skip them.

Do not force Angular patterns if you do not know Angular. NestJS is inspired by Angular, but you do not need to understand Angular to use it well.

Add validation early. Use the class-validator and class-transformer packages with NestJS pipes. They work seamlessly together and save you from a lot of manual validation code.

Write tests as you go. NestJS generates test files automatically. Use them. Future you will be grateful.

Common Mistakes Beginners Make

Putting logic inside controllers

Controllers should be thin. They receive a request and pass it along. If you are writing database queries or complex business rules inside a controller, move that logic to a service.

Ignoring the module system

Beginners often put everything into AppModule. This works at first and becomes a nightmare by week three. Create a module for each feature from the beginning.

Skipping TypeScript features

NestJS and TypeScript are deeply integrated. Using any everywhere or ignoring types defeats the purpose. Lean into TypeScript — it will actually help you.

Not using pipes for validation

Without validation pipes, invalid request data goes straight into your logic. Use ValidationPipe globally. It is one line of code and it prevents a lot of bugs:

app.useGlobalPipes(new ValidationPipe());

Trying to learn everything at once

NestJS has a lot of features. GraphQL, WebSockets, microservices, guards, interceptors, pipes, middleware. Do not try to learn all of it on day one. Start with modules, controllers, and services. Everything else comes naturally after that.

Is NestJS Worth Learning in 2025?

Absolutely. ⚡

NestJS has gone from an interesting framework to a mainstream choice for serious Node.js development. It is used by teams at companies large and small, across industries. The ecosystem is active, the documentation is strong, and the community keeps growing.

If you are building backends with Node.js and you want your code to be clean, scalable, and easy to work in as a team — NestJS is one of the best investments of your learning time right now.

You do not have to abandon what you already know. You just pick up better habits and better tools. And that is a pretty good deal.

Conclusion

NestJS is not just another framework. It is an answer to a real problem that Node.js developers have been dealing with for years: how do you build large, maintainable backends without inventing your own architecture every single time?

The answer NestJS gives is clear, practical, and well-executed. Modules keep your code organized. Controllers keep routing clean. Services keep business logic separate. TypeScript catches mistakes early. And the CLI keeps you moving fast.

If you are a beginner, NestJS gives you good habits to build on. If you are an experienced developer, it gives you structure that scales. Either way, it is worth your time.

Start small. Build one module. Write one service. Make one API endpoint. The framework will do the rest of the heavy lifting.

Enjoyed this post? Find more practical developer content at *hamidrazadev.com** — free tools, tutorials, and guides built for developers who like to keep things real.*

If this helped you, share it with a teammate or friend who is figuring out their backend stack. It might save them a few hours of confusion. 😊

Why Claude Fable 5 and Mythos 5 Were Banned: The Full Story Explained

Muhammad Hamid Raza — Tue, 16 Jun 2026 04:19:58 +0000

The AI world just got its most dramatic plot twist of 2026. Anthropic launched two groundbreaking models. The internet celebrated. And then, just three days later, they were gone — pulled from every user on the planet.

If you opened Claude last weekend and found Fable 5 missing, you were not alone. The disable was global, sudden, and still being disputed. What exactly happened? And why should any developer care?

Let's break it all down. 👀

What Are Claude Fable 5 and Mythos 5?

On June 9, 2026, Anthropic released two new AI models that sat in an entirely new tier above its flagship Opus line.

Claude Fable 5 was the publicly available version — available to all Claude Pro, Max, Team, and Enterprise users at no extra cost during a launch window. It was described as state-of-the-art on nearly all tested benchmarks, with exceptional performance in software engineering, knowledge work, vision, and scientific research. Its defining trait: the longer and more complex the task, the wider the gap between Fable 5 and everything that came before it. It could autonomously run agentic coding tasks for days with minimal human intervention.

Claude Mythos 5 was the same underlying model, but with some of its safety classifiers lifted. It was never public — only available to a small group of vetted cyberdefenders, critical infrastructure providers, and select biology researchers through Anthropic's restricted Project Glasswing program.

Together, they formed what Anthropic called the "Mythos class" — a new tier sitting above Opus. The name itself is intentional: Fable comes from the Latin fabula (related to the Greek mythos), drawing a clear line between the public-facing model and the less-restricted version.

Both models shared a 1 million token context window, support for up to 128k output tokens per request, and were priced at $10 per million input tokens and $50 per million output tokens — twice the Opus 4.8 rate.

Why This Topic Matters

This is not just another "new AI model" story. It touches something much more important for every developer, startup, enterprise team, and user anywhere outside the United States.

Within 72 hours of launch, the US government stepped in and ordered access cut off — not just in specific countries, but for every user on Earth. That is unprecedented. And the reason given — a potential jailbreak — is being actively disputed by Anthropic itself.

If you build on Claude, depend on its API, or care about where AI regulation is heading, this story affects you directly. It raises questions that no one has clean answers to yet:

Can a government pull a deployed commercial AI model without full explanation?
Who gets to decide what an AI model is "too dangerous" to deploy?
What happens to the hundreds of millions of users who depended on it?

This is the reality of frontier AI in 2026. The story is still unfolding.

What Made Fable 5 and Mythos 5 Powerful

Here is why these were not ordinary model releases — and why their capabilities became the heart of the controversy.

Autonomous, long-running tasks. Fable 5 could handle multi-day agentic workflows — things like reviewing an entire codebase, running a data pipeline, or executing complex software projects — without needing a human to check in every few steps. This was a major leap over Opus.
Exceptional cybersecurity capabilities. Mythos 5 was described by Anthropic as having "the strongest cybersecurity capabilities of any model in the world." It was particularly effective at identifying software vulnerabilities in complex, legacy systems that had been sitting unpatched for years. For defenders, that is incredibly useful.
Scientific breakthroughs. Anthropic's launch post mentioned that these models had contributed to genuine scientific output, including work on AAV (adeno-associated virus) candidates developed by Dyno Therapeutics — a striking example of AI directly assisting biological research.
Safety scaffolding built in. Sensitive topics like cybersecurity exploits, biology, chemistry, and model distillation triggered an automatic fallback to Claude Opus 4.8. Anthropic said these safeguards activated in fewer than 5% of sessions.
Massive context and output. With a 1 million token context window, Fable 5 could ingest entire codebases, lengthy legal documents, or vast research papers and reason over them in one shot.

Fable 5 vs Mythos 5: What Was the Difference?

They were built from the same foundation. The difference was in how much of the safety layer was kept on.

Feature	Claude Fable 5	Claude Mythos 5
Availability	General public, all paid plans	Invite-only (Project Glasswing)
Safety classifiers	Full safeguard layer active	Some safeguards lifted for vetted users
Who it served	Developers, enterprises, general users	Cyberdefenders, critical infrastructure, researchers
Cybersecurity scope	Broad tasks with automatic fallback	Higher-risk analysis for trusted organizations
Context window	1M tokens	1M tokens
Pricing	$10 / $50 per million tokens	$10 / $50 per million tokens
Data retention	30-day mandatory	30-day mandatory

In short: same brain, different safety gear. Fable 5 had its helmet on for the public. Mythos 5 had fewer restrictions for a trusted few.

What Happened: The Ban Explained Step by Step

Here is a clean timeline of how this unfolded.

June 9, 2026 — Launch Day
Anthropic releases Claude Fable 5 publicly and Claude Mythos 5 to Project Glasswing partners. Both are available immediately. Free access for Pro, Max, Team, and Enterprise plans announced through June 22.

June 9–11 — Early Adoption
Developers test it, benchmarks circulate, the community reacts positively. Fable 5 scores roughly 80% on SWE-Bench Pro in independent testing. Reviews highlight the long-horizon agentic performance.

June 12, 2026 — The Directive Arrives (5:21 PM ET)
The US government issues an export control directive, ordering Anthropic to immediately suspend access to Fable 5 and Mythos 5 for any foreign national — whether inside or outside the US — including Anthropic's own foreign national employees.

The directive cites national security authorities. The letter does not provide specific technical details.

June 12 Evening — Global Shutdown
Because verifying the nationality of every user globally is practically impossible, Anthropic decides that selective compliance cannot work. It disables both models for all customers worldwide.

"The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance," Anthropic stated. "Access to all other Anthropic models will not be affected."

June 13–14 — Anthropic Pushes Back
Anthropic publishes a detailed rebuttal. It says the government disclosed only a "narrow, non-universal jailbreak" — essentially a technique involving asking the model to read a codebase and fix any software flaws. Anthropic reviewed the demonstration and found that the vulnerabilities identified were minor, previously known, and discoverable by other publicly available models, including OpenAI's GPT-5.5.

Anthropic's technical team travels to Washington for meetings with White House officials.

June 15–16 — Still Under Review
Talks continue. Access has not been restored. Anthropic is maintaining compliance while arguing that the standard being applied would "essentially halt all new model deployments for all frontier model providers" if applied broadly across the industry.

What Anthropic Actually Said

Anthropic's official statement is worth reading carefully, because it explains not just what happened — but how the company thinks about safety.

The key points from Anthropic:

On the jailbreak itself: The government shared verbal evidence of a narrow, non-universal jailbreak. Anthropic reviewed what it believes was the basis of the directive, validated that the demonstrated capability was already available in other public models, and found that the technique identified only minor, previously known vulnerabilities.

On safeguards: Fable 5 went through thousands of hours of red-teaming with the US government, UK AISI, multiple third-party organizations, and internal teams before launch. No tester found a universal jailbreak — one that could broadly bypass the model's defenses.

On the standard being set: Anthropic warned that perfect jailbreak resistance is not possible for any model provider. Every deployed model in the industry is vulnerable to narrow jailbreaks in specific circumstances. If a narrow jailbreak is grounds for full recall, no frontier model should be deployed anywhere.

On compliance: Despite disagreeing, Anthropic is complying with the legal directive. "We believe this is a misunderstanding and are working to restore access as soon as possible."

Tips for Developers Right Now ⚡

If you had workflows or products relying on Fable 5 or Mythos 5, here is what you can do while access is suspended.

✅ Fallback to Claude Opus 4.8. For most development tasks, Opus 4.8 (released May 28, 2026) is still excellent. It is the next-most-capable model and remains fully available.

✅ Check Anthropic's status page and official blog. Updates on restoration will come from anthropic.com. Do not rely on social media rumors for this.

✅ Do not rebuild your entire architecture. This is a temporary disruption. Anthropic is actively working to restore access and is in direct talks with the White House. Migrating to a completely different provider right now may create more problems than it solves.

✅ Review your data retention understanding. Fable 5 and Mythos 5 required mandatory 30-day data retention. If your project had compliance questions around that, now is a good time to re-read the policy while waiting for access to return.

✅ Follow the story. This situation is evolving quickly. The outcome of Anthropic's talks with the Trump administration will likely shape how all frontier AI models are regulated going forward.

Common Mistakes and Misconceptions Around This Ban

Mistake 1: "Fable 5 was hacked or compromised."
No. The model itself was not hacked. The US government claimed a jailbreak technique was found that could bypass some of its safety filters. Anthropic disputes the severity of this finding. The model's architecture is intact.

Mistake 2: "This only affects users outside the US."
The export control directive targeted foreign nationals — but because Anthropic could not filter users by nationality in real time, it disabled access globally, including for US citizens. Everyone lost access.

Mistake 3: "This is Anthropic's decision."
Anthropic is complying with a legal government directive. The company actively disagrees with the move and is in discussions to reverse it. This was not a voluntary product recall.

Mistake 4: "Mythos 5 was a public model."
Mythos 5 was never publicly available. It was restricted to Project Glasswing partners — a small group of vetted organizations in cybersecurity, critical infrastructure, and biology research.

Mistake 5: "All Claude models are now unavailable."
Only Fable 5 and Mythos 5 are suspended. All other Claude models — including Claude Opus 4.8, Claude Sonnet 4.6, Claude Haiku 4.5, and others — remain fully available.

Mistake 6: "This proves AI models are dangerous and should be stopped."
The demonstrated jailbreak found minor, previously known vulnerabilities that other public models can also discover. The debate is about regulatory standards and how to define acceptable risk — not about Fable 5 being uniquely dangerous.

What This Means for the Broader AI World

This is the first time a deployed commercial AI model has been pulled globally by government order within days of launch. That alone makes it a defining moment.

The precedent it sets is still being negotiated. Anthropic has publicly argued that if a narrow jailbreak — one that reveals minor vulnerabilities already discoverable by other public models — is sufficient cause for a full global recall, it would make future frontier model deployments nearly impossible.

The Trump administration had already designated Anthropic a "supply-chain risk to national security" in March 2026 (a designation Anthropic contested). This action appears to be a continuation of that tension.

How this gets resolved will send a strong signal to every AI lab, every government, and every developer who builds on top of these models.

Conclusion

Claude Fable 5 and Mythos 5 were arguably the most capable AI models ever made publicly available. They lasted three days.

The story is not really about whether a jailbreak exists — narrow jailbreaks exist for every model in the industry. The story is about who gets to define the line between "safe enough to deploy" and "too dangerous to ship," and what process they follow to make that call.

Anthropic is disputing the ruling, complying with the law, and working to restore access. The broader question of how governments should regulate frontier AI is now front and center — and every developer who builds on these tools has a stake in how it resolves.

Stay updated, keep an eye on anthropic.com, and in the meantime, Claude Opus 4.8 has your back. 🚀

If this breakdown helped you understand what happened, share it with your team or community — a lot of people are confused about this story. And for more developer-focused content, head over to hamidrazadev.com for articles on AI, frontend development, and the tools shaping how we build.

DEV Community: Muhammad Hamid Raza

VS Code 1.128 Is Here: Multi-Chat Agent Sessions, Copilot Vision, and OS-Level Shortcuts 🚀

What Is VS Code 1.128?

Why This Release Matters

Benefits with Real-Life Examples

Beginner Approach vs Better Approach: Managing Multiple AI Conversations

Best Tips for Using These New Features

Common Mistakes People Make

Wrapping Up

The New HTTP QUERY Method: Why GET and POST Weren't Enough

What Is the HTTP QUERY Method?

Why This Topic Matters

Benefits with Real-Life Examples

GET vs POST vs QUERY: Quick Comparison

Best Tips for Using QUERY

Common Mistakes People Make

Wrapping Up

Visual Studio Code 1.127: Everything New in the July 2026 Update

What Is Visual Studio Code 1.127?

Why This Update Matters

What's New in Visual Studio Code 1.127

🌐 Browser Tools for AI Agents Are Now Generally Available

🔒 Per-Site Browser Permissions

📂 Better Agent Session Organization

💬 Chat Input Banners

💰 Subagent Credit Visibility

✨ Improved Multi-Chat Sessions

⚡ Better Session Layout

🛠️ /troubleshoot for AI Sessions

🧪 Terminal Sandboxing

🤖 Built-in Ollama Provider Deprecation

Benefits with Real-Life Examples

Visual Studio Code 1.127 vs Earlier Versions

Best Tips

✅ Do

❌ Don't

Common Mistakes Developers Make

Ignoring release notes

Treating AI like autopilot

Keeping messy sessions

Forgetting extension updates

Final Thoughts

DX Matters Too: Why Developer Experience Deserves the Same Love as UX

Introduction

What Is Developer Experience (DX)?

Why Developer Experience Actually Matters

Real Benefits of Prioritizing DX (With Examples)

UX vs DX: Two Sides of the Same Coin

Best Practices: How to Improve DX

Common Mistakes That Kill Developer Experience

Conclusion

All npm Dependency Types Explained: dependencies, devDependencies, peerDependencies, and More

What Is a Dependency in npm?

All Dependency Types in npm

1. dependencies — The Production Essentials

2. devDependencies — The Dev-Time Helpers

3. peerDependencies — The Sharing Agreement

4. peerDependenciesMeta — The Peer Dependency Modifier

5. optionalDependencies — The Nice-to-Have

6. bundledDependencies — The Package-in-a-Package

7. npm Install Save Flags — How Each Type Gets Added

--save or -S (Default since npm v5)

--save-dev or -D

--save-optional or -O

--save-peer (npm v7+)

--save-bundle or -B

--save-exact or -E

--no-save

Quick Visual Summary

Why This Actually Matters (Real Impact)

Common Mistakes Developers Make

❌ Installing everything under dependencies

❌ Using dependencies instead of peerDependencies in a library

❌ Ignoring optionalDependencies error handling

❌ Confusing peerDependencies with devDependencies

Do's & Don'ts

Conclusion

VS Code 1.126: Track AI Costs, Run Multiple Chats, and Browse Code Safely

What Is VS Code 1.126?

Why This Release Matters

1. `dependencies` — The Production Essentials

2. `devDependencies` — The Dev-Time Helpers

3. `peerDependencies` — The Sharing Agreement

4. `peerDependenciesMeta` — The Peer Dependency Modifier

5. `optionalDependencies` — The Nice-to-Have

6. `bundledDependencies` — The Package-in-a-Package

`--save` or `-S` (Default since npm v5)

`--save-dev` or `-D`

`--save-optional` or `-O`

`--save-peer` (npm v7+)

`--save-bundle` or `-B`

`--save-exact` or `-E`

`--no-save`

❌ Installing everything under `dependencies`

❌ Using `dependencies` instead of `peerDependencies` in a library

❌ Ignoring `optionalDependencies` error handling

❌ Confusing `peerDependencies` with `devDependencies`