WebStorm 2025.3 is now available!
After months of development, this release brings a host of new features and improvements. Highlights include:

• Service‑powered type engine gradual enablement for more accurate TypeScript type evaluation.
• Enhanced module resolution and monorepo support, with improved handling of pnpm and Nx workspaces.
• Upgraded AI Assistant with Claude Agent and Junie integration in a single chat.
• Remote debugging for JavaScript projects in WSL, Docker, and dev containers, including the ability to launch a browser on your local machine during remote sessions.
• Webref‑aligned CSS syntax update, bringing support for the latest specs and adding new math functions like round(), rem(), and mod().
• Unified JavaScript Runtime settings page that consolidates Node.js, Bun, and Deno configuration.
• Vitest 4 support, enabling the correct discovery and execution of tests written for the latest Vitest version.

This release also includes numerous fixes and quality‑of‑life enhancements for TypeScript, Angular, Vue, Astro, Prettier, and more.

You can update to WebStorm 2025.3 via the Toolbox App or download it directly from our website. We can’t wait for you to try it. Please let us know what you think – your feedback helps make WebStorm better with each release. Happy coding!

DOWNLOAD WEBSTORM 2025.3

Key improvements

TypeScript 

Service‑powered type engine 

The experimental type engine introduced via the WebStorm@next program now has an official name: the service‑powered type engine. This engine delegates type evaluation to the TypeScript language service instead of WebStorm’s internal type resolver. It generally reduces CPU usage, improves performance in many scenarios, and ensures better compatibility with native TypeScript behavior.

Starting from 2025.3, this engine will be enabled gradually for a subset of WebStorm users. Other JetBrains IDEs remain unchanged, so their TypeScript experience is not affected. A status bar widget indicates the engine status, and you can also submit bug reports from this widget.

Better module resolution and monorepo support

WebStorm 2025.3 uses the customConditions property in tsconfig.json and “development” conditions in exports fields to support build‑free editing (see the Node.js documentation). This means auto‑imports, Go to Definition, and Find Usages work without building output directories. The automatic import mechanism has also been improved for pnpm symlinked packages. To ensure TypeScript correctly detects workspace packages, we suggest using explicit exports entries and moduleResolution:"nodenext" (WEB-74887).

Detecting out‑of‑memory errors in the TypeScript service

Large TypeScript projects can occasionally trigger out‑of‑memory (OOM) errors in the TypeScript language service. To help you diagnose and resolve these issues, WebStorm now monitors stderr output for specific OOM messages and presents a notification suggesting that you increase the service’s heap size.

File extension handling and .mts support 

Several long‑standing issues with module extensions have been resolved. A fix in WebStorm 2025.2.3 and 2025.3 prevents .mjs files from replacing .mts in auto‑imports. There is also a proposal to honor TypeScript 5.0’s allowImportingTsExtensions flag via Code Style | TypeScript | Use file extension = “Auto”. With this configuration, .ts or .js will be chosen automatically based on your moduleResolution setting and whether allowImportingTsExtensions is true (WEB-60748).

AI Assistant: Junie and Claude Agent integration

In this release, Claude Agent is now available natively inside the JetBrains AI Assistant chat interface! Agents have full access to IDE capabilities via the JetBrains MCP server.

New default look: The Islands theme

The Islands theme is now the default look in WebStorm and other JetBrains IDEs. Designed to help you stay focused and code with ease, it features instantly recognizable tabs, enhanced in-editor contrast, distinct separation between work areas, and rounded corners. This update is purely visual, so all functionality remains unchanged.

Debugging JavaScript projects in remote environments

You can now use WebStorm’s built-in JavaScript debugger when developing remotely with WSL, Docker, or other remote setups. 

For frontend projects, the IDE launches a browser on your client machine that connects back to the remote environment, allowing you to set breakpoints and step through your code with the same workflow you use locally. WebStorm 2025.3 includes support for JavaScript debug and npm run configurations. We’re actively gathering feedback to guide further improvements.

Angular

• Angular 20.2 as aliases in else if blocks – WebStorm now understands the new syntax introduced in Angular 20.2, allowing aliases in @else if conditions. Available in WebStorm 2025.3, this fix will also be backported to 2025.2.3.
• Support for Angular 20.1’s binary assignment operators (+= and -=) in template bindings is now available in WebStorm 2025.2.1 and 2025.3 (WEB‑73861).

Vue

• Initial Vapor mode support – Vue 3.6 introduced Vapor mode, a lightweight compiler that eliminates the runtime. WebStorm 2025.3 adds initial support for this, including:
  • Recognition of the new createVaporApp factory function – directives registered in the application are treated as Vapor directives.
  • The New Vue Component wizard can now generate Vapor components that use either <script vapor> or <script setup vapor>.
  • Directives declared in a component’s script section or registered via an application or plugin are recognised – global directives are partially supported.
    
• Composition and two‑script blocks – WebStorm now supports multiple <script> blocks in single file components.
  
• Plugin‑registered directives – Vue 3 directives registered through plugins are now recognized. WebStorm 2025.3 adds support for both plugin forms (function and object with install). Directives are collected when the plugin is registered using app.use(myPluginWithDirectives), but not when the plugin is invoked as a function (WEB-52800).
  
• Global components and global directives – We’ve fixed the issue where global components declared in the GlobalComponents interface were not resolved. Our fix adds support for .d.ts files in the types field of compilerOptions and makes the .d.ts extension optional. Additionally, WebStorm 2025.3 implements support for the GlobalDirectives interface, for example, Vuetify’s vVuetifyClickOutside.
  

CSS

WebStorm 2025.3 includes a major CSS syntax data update based on synchronization with WebRef. This generic solution brings the latest specification data into the IDE, ensuring modern and accurate CSS support.

This includes support for math functions round(), rem(), and mod(), as well as color-related features like color(), conic-gradient(), and others. If you encounter issues or have suggestions, please comment on the umbrella issue.

Vitest

Vitest 4 introduced breaking changes to its reporter API, which previously caused WebStorm to show No tests found errors for Vitest 4 suites. The integration has been updated to work with the new API and is available in the 2025.3 release.

Astro

Fixes to the Astro parser remove false errors when using expressions inside HTML tags and eliminate incorrect highlighting of truthy tags (WEB-60565, WEB-69032). 

These changes make Astro templates behave correctly in the IDE. In parallel, the team is working on a broader update to align WebStorm’s Astro support with the official Astro Language Server for even better compatibility in a future release.

Prettier

The new Prettier language status widget indicates whether the current file is handled by Prettier, displays any formatting errors on save, and provides a Go to Configuration File action for quick access to your .prettierrc or equivalent configuration files.

WebStorm can now automatically run Prettier when you paste code, ensuring that pasted snippets immediately conform to your project’s Prettier configuration. You can enable or disable this behaviour in the Code Style settings.

Unified JavaScript Runtime settings page

WebStorm 2025.3 introduces a unified JavaScript Runtime settings page that consolidates Node.js, Bun, and Deno configuration. From this single page, you can configure interpreters for all supported runtimes and select the appropriate one for .js or .ts run configurations. Please keep in mind that Node.js is still used for the TypeScript and language servers (WEB‑73571).

If you’d like a list of everything included in WebStorm 2025.3, please check out the release notes. As always, please share your feedback with us and report any issues you find to our issue tracker.

The WebStorm team

As Microsoft steps into the Ignite 2025 era of “AI-first everything” across Azure, Foundry, and cloud-native workloads, .NET quietly got its own big upgrade: .NET 10, a new long-term support (LTS) release and the official successor to .NET 9, supported for three years.

The release was celebrated at .NET Conf 2025 in November, where Microsoft shipped .NET 10 alongside Visual Studio 2026 and highlighted performance, memory efficiency and cloud-readiness as core pillars of the platform. A few days later at Microsoft Ignite 2025 in San Francisco, the story zoomed out: AI agents, Azure-hosted workloads, and App Service / Functions all moved forward with first-class .NET 10 support, positioning this runtime as the default foundation for modern cloud and AI solutions.

I’m Hazem Ali, a Microsoft MVP, Principal AI & ML Engineer / Architect, and Founder & CEO of Skytells. 

In this article, I’ll walk through what .NET 10 actually changes in memory, heap, and stack behavior—and why that matters if you’re building high-throughput APIs, AI agents, or cloud-native services in the post-Ignite world.

At a high level, .NET 10 does three big things for memory:

1. Allocates more objects on the stack instead of the heap.
2. Teaches the JIT to understand more “hidden” allocations (delegates, spans, small arrays).
3. Leans on a smarter GC mode (DATAS) that adapts heap size to your app instead of your machine.

Let’s unpack that in plain language.

---

1. Heap vs Stack in 60 Seconds

Quick mental model:

• Stack

  • Used for short-lived data.
  • Allocation is extremely fast — often just advancing a pointer.
  • Memory is released automatically when the function returns.
  • Very cache-friendly due to tight, contiguous layout.

  Heap

  • Used for long-lived or shared objects.
  • Allocation is slower and requires runtime management.
  • Objects are tracked by the garbage collector (GC) in managed runtimes.
  • Creating too many short-lived objects on the heap increases GC pressure, which can lead to pauses and more cache misses.

So any time the runtime can say:

“This object definitely dies when this method returns”

…it can put it on the stack instead, and the GC never has to care.

.NET 10’s main memory trick is expanding how often it can safely do that.

---

2. From Heap to Stack: .NET 10 Gets Serious About Escape Analysis

The JIT in .NET 10 spends more effort answering one question:

“Does this object escape the current method?”

If the answer is “no”, it can be stack-allocated. This is called escape analysis, and .NET 10 pushes it much further than .NET 9.

2.1 Delegates and Lambdas That Don’t Leak

Consider this simple closure:

int SumTwice(int y) { Func<int, int=""> addY = x => x + y; return DoubleResult(addY, y); static int DoubleResult(Func<int, int=""> f, int v) => f(v) * 2; }</int,></int,>

The C# compiler turns that into:

• A hidden closure class with a field y.
• A delegate object pointing at a method on that closure.

In .NET 9, both of these lived on the heap.

In .NET 10, if the JIT can inline DoubleResult and prove the delegate never escapes the method, the delegate object is stack-allocated instead. Benchmarks in the official performance blog show:

• ~3× faster for this pattern
• ~70% fewer bytes allocated (only the closure remains on the heap)

You don’t change the code; the JIT just stops paying the “lambda tax” as often.

---

2.2 Small Arrays of Value Types on the Stack

.NET 10 adds the ability to stack-allocate small, fixed-size arrays of value types (that don’t hold GC references) when they clearly don’t outlive the method.

Example from the official docs:

static void Sum()
{
    int[] numbers = { 1, 2, 3 };
    int sum = 0;

    for (int i = 0; i < numbers.Length; i++)
        sum += numbers[i];

    Console.WriteLine(sum);
}

The runtime article explicitly states that numbers is now stack-allocated in this scenario, because:

• The size is known at compile time (int[3]).
• The array never escapes the method.

Result: no heap allocation for that small buffer, and one less thing for the GC to track.

---

2.3 Small Arrays of Reference Types

Historically, arrays of reference types (string[], object[], etc.) have always been heap allocations in .NET, and this remains true in .NET 10. The GC must track the references stored in these arrays, which makes stack allocation impossible.

However, .NET 10 significantly reduces the cost of using small ref-type arrays by improving escape analysis around the patterns that create and consume them. While the array itself still lives on the heap, many of the associated allocations that previously accompanied these patterns can now be eliminated entirely.

Example:

static void Print()
{
    string[] words = { "Hello", "World!" };
    foreach (var s in words)
        Console.WriteLine(s);
}

In .NET 9, using a small string[] like this typically incurred extra hidden allocations (iterator objects, closure artifacts, helper frames).

In .NET 10, if the JIT can prove the code is fully local and non-escaping:

• Iterator-related allocations can be removed,
• Delegate and closure helpers may be stack-allocated or optimized away,
• The only remaining heap object is the array itself — with no additional GC noise.

A similar pattern appears in the performance blog’s benchmark:

[Benchmark]
public void Test()
{
    Process(new string[] { "a", "b", "c" });

    static void Process(string[] inputs)
    {
        foreach (string input in inputs)
            Use(input);

        static void Use(string s) { }
    }
}

On .NET 10, this benchmark shows zero additional heap allocations beyond the array itself, because the runtime eliminates the iterator and closure allocations that .NET 9 would create. The array still resides on the heap, but the overall memory footprint effectively drops to zero for the surrounding pattern.

---

2.4 Structs, Spans, and “Hidden” References

.NET 10’s improved escape analysis can recognize when neither the struct nor its referenced array escapes, enabling the runtime to eliminate unnecessary heap allocations around the pattern.

From the runtime docs:

struct GCStruct
{
    public int[] arr;
}

public static int Main()
{
    int[] x = new int[10];
    GCStruct y = new GCStruct() { arr = x };
    return y.arr[0];
}

• In .NET 9, x is treated as escaping (through y) and lives on the heap.
• In .NET 10, the JIT understands that neither y nor x escapes, so it can stack-allocate the array and associated data.

This also benefits types like Span (which is just a struct with a reference and a length) and unlocks more cases where spans and small arrays become stack-only, not heap noise.

---

3. DATAS: The GC That Adapts to Your App Size

On the GC side, the key concept is DATAS – Dynamic Adaptation To Application Sizes.

• Introduced as an opt-in mode in .NET 8.
• Enabled by default in .NET 9.

By the time you land on .NET 10 LTS, DATAS is the default GC behavior for most apps, with more tuning and guidance from the GC team.

3.1 What DATAS Actually Does

Official docs describe DATAS as a GC mode that:

• Adapts the heap size to the app’s memory requirements,
• Keeps the heap size roughly proportional to the live (long-lived) data size,
• Shrinks when the workload gets lighter and grows when it gets heavier.

That’s different from classic Server GC, which:

• Assumes your process “owns” the machine,
• Grows the heap aggressively if there’s memory available,
• May end up with very different heap sizes depending on hardware.

DATAS is especially targeted at bursty workloads and containerized apps where memory actually costs money and you might have many processes on the same node.

3.2 How You Control It

From the GC configuration docs:

DATAS can be toggled via:

• Environment variable:

  • DOTNET_GCDynamicAdaptationMode=1 → enable
  • DOTNET_GCDynamicAdaptationMode=0 → disable

• runtimeconfig.json:

  • "System.GC.DynamicAdaptationMode": 1 or 0

• MSBuild property:

  • 1

But again: starting with .NET 9, it’s on by default, so in .NET 10 you typically only touch this if you have a very specific perf profile where DATAS isn’t a good fit.

---

4. What This Means for Your Apps

Putting it together:

You get fewer “silly” allocations for free

.NET 10’s runtime now:

• Stack-allocates more delegates, closures, spans, and small arrays when they don’t escape.
• Reduces the abstraction penalty of idiomatic C# (LINQ, foreach, lambdas, etc.), so you don’t have to micro-optimize everything yourself.

The GC behaves more like “pay for what you really use”

With DATAS:

• Your heap won’t balloon just because you moved your app to a bigger SKU.
• Memory usage tracks live data instead of “whatever the machine has spare”.

You still keep control when needed

If you have:

• A latency-critical, always-hot service on a big dedicated machine,
• Or you’ve benchmarked and found DATAS not ideal for a specific scenario,

…you can still flip DOTNET_GCDynamicAdaptationMode off and go back to classic Server GC semantics.

---

5. TL;DR for Busy Teams

If you’re scanning this on a Friday:

• Upgrading from .NET 8 → 10 LTS gives you:

  • Tuned DATAS GC as the default,
  • Better JIT escape analysis,
  • Stack-allocation of more small arrays and delegates.

• You don’t need to rewrite your code to benefit; just recompile and deploy.

• For critical services, benchmark with and without DATAS (toggle via DOTNET_GCDynamicAdaptationMode) and pick what fits your SLOs.

That’s the memory game-changer in .NET 10: the runtime quietly moves more stuff off the heap, while the GC learns to grow and shrink based on your real live data, not just the machine it’s sitting on.

In this episode of the VS Code Insiders podcast, James sits down with Julia to explore the fast-changing world of AI models inside VS Code. They dive into how developers can evaluate models, the role of fine-tuning, and why speed versus complexity matters. From Raptor Mini to Sonnet, this conversation reveals the behind-the-scenes work shaping your coding experience today.

Follow VS Code:

• X: https://x.com/code
• Bluesky: https://bsky.app/profile/vscode.dev
• YouTube: https://youtube.com/code
• LinkedIn: https://www.linkedin.com/showcase/104107263
• GitHub: https://github.com/microsoft/vscode

Special Guest: Julia Kasper.

Links:

• Raptor Mini

Download audio: https://aphid.fireside.fm/d/1437767933/fc261209-0765-4b49-be13-c610671ae141/a70c9acd-9575-41f3-9ec5-ef6d30e7b9a5.mp3

James and Frank break tradition by recording Merge Conflict together in person, sharing laughs about ferries, sea shanties, and their annual Seattle holiday meetup. The conversation dives deep into Swift Data versus Core Data, CloudKit syncing, and the quirks of building modern apps with AI assistance. Along the way, James reveals his new weight‑tracking app experiment, complete with charts, HealthKit integration, and lessons learned from coding on planes and trains.

Follow Us

• Frank: Twitter, Blog, GitHub
• James: Twitter, Blog, GitHub
• Merge Conflict: Twitter, Facebook, Website, Chat on Discord
• Music : Amethyst Seer - Citrine by Adventureface

⭐⭐ Review Us ⭐⭐

Machine transcription available on http://mergeconflict.fm

Support Merge Conflict

Links:

• Test James' App

Download audio: https://aphid.fireside.fm/d/1437767933/02d84890-e58d-43eb-ab4c-26bcc8524289/83e8fa7b-4907-461b-a340-193acd2ade81.mp3

Read the full article at https://www.htmhell.dev/adventcalendar/2025/8/

We are excited to announce that we will be returning to CodeMash 2026 as a sponsor and exhibitor. Join us to learn about the latest in .NET development and how our products can help you build better applications.