I know some people don't, but I enjoy modernizing legacy codebases 😁 But... only when I'm being paid to. When it's my codebase, I hate it because it's my fault 😂

This is a good deep dive into the difference. You do not need the tsconfig decorator options turned on to use Stage 3 decorators today: medium.com/@aude.lellou...

This is not intuitive if you have used experimental decorators. That is now legacy and not recommended unless you're on TS < 5.

Because Aspire is... just code... I can do fancy things like customize how authentication works, or even disable MCP tools (using List Tool Calls Filter) that require things the user doesn't opt-into by default. This makes the course demo WAY EASIER to run and set up without worrying about infra.

I tested it on my MacBook this morning. Yes, you need plenty of prereqs (.NET, Docker/Podman, Node, Az Func Core Tools) but... once you have the environment setup, `aspire run` just works and the MCP server can be used by VS Code immediately. All the tools work too except for AI search.

I will say this: the demo app for the Advanced MCP course is pretty 🔥

This is all running locally in Aspire. It does require live resources (like Entra ID tenant) but still, it all will... just work 🤯

And I haven't tested but once I deploy this remotely, Claude should support the demo MCP finally

correction: that's actually TWO calls to the backend API in one MCP tool request. the long bar = az function cold start (even locally), but notice that its a few ms after it gets warmed up there at the end

All just to call a backend API as the employee. couldn't be that hard could it?

Shout out to @rspack.dev for making Rsdoctor which is amazing 😍

Goes beyond webpack bundle analyzer.

Plenty of optimizations left but these were done in one night worth of investigation, and deployed to prod today.

Bundle optimizations:

- split big vendor from main and mark async
- cache core app code separately vs sharing across multiple entry points

Results?

40mb -> 22mb (dev, initial, source size)

5.5mb -> 2.3mb (prod, initial, uncompressed)

850kb -> 650kb (prod, initial, gzip)

I'll take it! 🎉

If you're using (classic) app insights then you need to be looking at telemetry processors for adding context. If you're using (modern) OTel libraries (still with app insights, yes that's separate and yes that's confusing af), you can do the same:

learn.microsoft.com/en-us/azure/...

Yeah, this one!

eslint.org/docs/latest/...

Okay, that makes sense, as long as nobody accidentally imports vendored deps. Maybe there's a way to catch that? Either define a lint rule, I think there's one about not allowing package imports we used to use.

We should probably maintain a list but we try to share cool libraries (big or small). They are in the show notes of each episode for @typescript.fm . I should just slurp those up into a dedicated page.

Otherwise, it would have proceeded to refactor and add additional types/code to the project. In the end, this might still be what they want me to do, but I thought the source generator was much cleaner.

This is worth a longer blog post but initially I asked Copilot to make a plan to add compatibility. It never suggested using a polyfill package. Of course, I didn't know to ask it to. But it goes to show you cannot blindly just do a migration/upgrade, you also need to research your options before.

The cool thing I learned about today is source generator polyfills. The one I added polyfills a bunch of APIs and lets you use modern C# 14 syntax like ranges and index expressions and destructuring without modifying your code. I don't know if they'll take on the dependency.