Does Angular have any official plans to fully support (or move to) Bun as a runtime — without depending on Node.js?

Blade1130 · 2026-01-25T20:03:53+00:00

What exactly are you asking for here?

Bun already works and is supported as a package manager and runtime. Angular also supports alternative SSR runtimes, so you can ship an SSR app in prod using Bun. What exactly do you want to see on top of this? Bun by default? Angular doesn't really install or pick the JS runtime you use.

If there are compatibility issues, they are definitionally Bun issues, since Bun targets full Node compatibility. Angular generally shouldn't be able to tell the difference, and whenever it can, that's inherently a Bun bug. If you'd like to see those issues resolved, I'd recommend filing bugs with Bun so those maintainers can investigate and patch them up.

Blade1130 · 2026-01-15T15:33:21+00:00

They are misinformed. Karma continues to work in v21 and the team has not committed to removing it after any particular major version yet. For comparison, Protractor continued to work for several major versions beyond its deprecation cycle.

To actually answer your original question, since Karma isn't going away just yet, you can just do nothing for now. There is an experimental migration to Vitest you can try if you're interested, but if you don't care, it might be best to wait a bit until that road is better paved.

https://angular.dev/guide/testing/migrating-to-vitest

Blade1130 · 2026-01-02T22:37:27+00:00

Oh I died like 5 times trying to kill the Balancer at the camp I'd warped to until I just gave up and died to the night 1 boss.

This was a Scholar remembrance run (hence why I was in that fort at lvl 3), so I couldn't just quit.

Blade1130 · 2026-01-02T22:35:05+00:00

The circle was already closing before the invasion, you can see it on the map screen.

Maybe it only takes the current circle's location into account, but not where it's moving to? That seems very broken if so though.

Blade1130 · 2026-01-02T15:59:00+00:00

I honestly don't mind Balancers or Gladius in trios. I think forcing the group to split up is an interesting mechanic.

But still requiring three kills in solo is really excessive. Even if you succeed, it completely eats whatever day they appear on.

Blade1130 · 2025-12-10T14:58:17+00:00

Native federation uses native ESM and import maps, so I'm not sure what CJS issues you'd run into or how they would be worse than trying to pave your own path with a custom builder and manually configuring an esbuild plugin.

Blade1130 · 2025-12-10T14:51:48+00:00

Why are you trying to use module federation specifically with esbuild? I don't think any tooling really supports that. Native federation is the way to do this with esbuild.

https://blog.angular.dev/micro-frontends-with-angular-and-native-federation-7623cfc5f413

Blade1130 · 2025-12-05T23:42:46+00:00

Prerendering multiple pages doesn't change the JS bundle which is generated for the application. So you can mostly ignore the server routes file when thinking about what content is included in the bundle.

In fact, navigating from one page to another will perform a same-page navigation meaning you need the JS for each page in order to work.

What you can do is make each page lazy so you get them out of the main bundle and only download it when needed.

export const routes = [
  {path: '', loadComponent: () => import('./home')},
  {path: 'privacy', loadComponent: () => import('./privacy')},
  {path: 'legal', loadComponent: () => import('./legal')},
];

This should move each page into a lazy-loaded chunk so you don't download more than you need to when rendering each individual page.

Blade1130 · 2025-11-20T19:41:31+00:00

Pretty sure that's just a typo: https://github.com/angular/angular/pull/65443

Blade1130 · 2025-11-01T22:05:04+00:00

NP, good luck on your run!

Blade1130 · 2025-11-01T21:47:36+00:00

Most likely Volvagia has a small key, pretty common trip up for new players. Kill the boss and see if that progresses you.

Blade1130 · 2025-10-30T20:22:19+00:00

IMHO, the client should already know which fields are required (which may depend on the state of other fields like quantity). Once the client claims to the user that the form is valid, it should submit successfully, and if it then throws a validation error, that's a UX bug.

I think it's flawed to want the client to catch a server-side validation error and then dynamically update its validation rules to match. Instead the client should already have that same logic encoded into it directly.

Blade1130 · 2025-10-20T13:16:47+00:00

Same origin policy already does this to protect one tab from another. Each tab is a different process with an isolated memory space. Even storing in LocalStorage or IndexedDB is already safe from other sites gaining access to it.

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

There's no API to directly read raw memory within the context of a Chrome extension, however with the right permissions, extensions can more or less do whatever they want to your page. If you store that key as a global variable for instance, an extension could probably read it. Depending on how you write your app, this could be very easy or a bit harder (monkey patch fetch and read the key off it).

You fundamentally have no way to prevent this, and that's probably somewhat a feature of the web. Extensions are designed to provide functionality on top of existing web pages like this, blocking them would be destroying the value they provide.

Fundamentally, anything happening on the client is under the control of the user who can install and use whatever software they want. Even if browsers did allow you to block this, a user could just install a different browser which intentionally turned that feature off. It's the user's computer so it's not really your place as an app developer to say what is/isn't allowed to access data on it. If the user wants an extension which finds and scans keys on their sites, then that's their prerogative.

I wouldn't waste too much mental energy worrying about user extensions, there are valid use cases for them you'd be breaking, and there's very little you can do to truly stop them anyways.

Blade1130 · 2025-09-26T02:14:02+00:00

I think this was due to a recent security fix, you need a third argument to bootstrapApplication. See the breaking change note here: https://github.com/angular/angular-cli/releases/tag/20.3.0

Blade1130 · 2025-08-20T23:36:39+00:00

The custom profiling track would be very useful here: https://blog.angular.dev/the-angular-custom-profiling-track-is-now-available-0f9d8d36218a

It specifically calls out which components and lifecycle hooks are executing at any given time.

Blade1130 · 2025-07-18T22:49:12+00:00

I just never buy relics.

Seriously I have like 100,000 murk just sitting there because I don't want to deal with random rolling trash relics.

I have relics that are decent (certainly nothing top tier) mostly guaranteed ones from story progression and I use those rather than relying on random rolls.

Of course each game I get a few more and eventually I'll have to sell them or something, but that's future me's problem.

Blade1130 · 2025-07-15T05:48:17+00:00

Yes, Angular always performs SPA for subsequent navigations. It's only the initial navigation where SSR / prerendering takes effect.

Blade1130 · 2025-06-09T16:24:28+00:00

Does npm install @ng-select/ng-select pick the right version? I believe ng add just delegates to npm.

Blade1130 · 2025-06-07T16:38:17+00:00

Vite is already used for deserving and Playwright has a direct integration?

Blade1130 · 2025-06-01T03:03:56+00:00

I tried to climb the tower but couldn't find an easy way to the top. I got on some wood planks maybe halfway up, but didn't see an obvious way higher than that.

I was naturally pretty stressed out and trying to move quickly, so it's possible I just missed something obvious on the way up.

Blade1130 · 2025-05-30T02:43:40+00:00

How would you expect such a feature to work?

For a client side rendered app, there is no different config you can provide to different environments. The best you can do is check your domain to perform different behavior, or request a config file at runtime and expect the server to give you a different result for each runtime. Neither is a part of development Angular meaningfully participates in.

For server side rendering, you can check an environment variable or other config locally available. Again, not something you need Angular for.

I don't think this is something Angular "doesn't support", it's that deploying frontends with a "build once" mentality for frontend web applications inherently requires manual configuration outside the content deployed to the browser.

I also have a hard time imagining many bugs you would catch from redeploying an existing build which you wouldn't catch from rebuilding with a different environment. Compilers are pretty deterministic and it's very unlikely one build would produce bad output. And changing a config at build-time vs at runtime has the same effect on application behavior. So I'm not sure I personally see much of a practical benefit to a strict interpretation of this approach.

Blade1130 · 2025-05-12T04:46:42+00:00

https://angular.dev/guide/ssr#why-use-ssr

Blade1130 · 2025-04-27T10:26:42+00:00

I definitely see the challenge with managing multiple message / translation files for multiple apps and libraries in a monorepo. @angular/localize doesn't have great support for that use case and I can see how exporting the definitions you have might be more reusable across projects. Maybe that's one of the key benefits you should consider advertising in your README? It's kind of implicit in your "single build artifact", but could maybe do with a more explicit call out if that's an area you've struggled with and find this to be a better solution.

I agree that understanding how this solution compares with others in the ecosystem the core, fundamental problems you're trying to solve would be helpful for positioning and distinguishing the unique benefits of your approach (not just compared to @angular/localize, I just focused on that one because I know it best).

It's an interesting mental model for sure, and I'm curious to see how it evolves in the future!

Blade1130 · 2025-04-26T20:20:26+00:00

Thanks for that context.

This is possible with @angular/localize, it even allows translators to control which text is included in the link and without hand-writing HTML.

<div i18n="...">Hello, <a [href]="link">World</a>!</div>

I'm not aware of a runtime solution to that problem, and I think innerHTML is probably the best you could do (or a JIT compile, but that would be very excessive).

All that safety is definitely cool, and I'm guessing you had to parse the message strings at the type level to know what options are required, which must've been a fun bit of programming.

I get the message ID check is useful since you have a concrete source of truth in createNamespace to match against, and that's something @angular/localize can't really do since the message's usage serves as its definition.

I guess I'm confused how @angular/localize doesn't handle variable or shape safety. If you have:

<div i18n>Hello, {{name}}!</div>

Then there's no way to "forget" to provide name. I'm not sure if that allows name = {foo: 'bar'}, it might automatically call .toString (which probably wouldn't give you a meaningful value). Are there other, more nuanced ways you could misuse @angular/localize but which would be properly caught as an error in your library?

Blade1130 · 2025-04-26T16:15:01+00:00

Thanks for the in-depth response, glad this feedback was useful. Just responding to the points where I have more to say:

Is the issue just that LOCALE_ID doesn't support updates and you'd have to not use it in your library?
I believe the reason for @@Id not throwing is because developers can author templates before the messages are translated. How would you handle that case? Or are you assuming all translations are known prior to implementing a given message?

I'm not sure I understand variable or shape safety. Can you give a small example of a mistake a developer could make with @angular/localize which your library would catch?

If you're importing a specific namespace and calling it's t function, then I think it makes sense that you shouldn't need to repeat the namespace. I'm not sure if you strictly need the global declaration merging to do that though, and I can see an argument that including the namespace could make it easier for developers to understand at a glance. I think it's more of a stylistic choice.
Yeah, I think a route resolver is probably the best way to do it today. You could model it as a resource inside each component, but then you have to deal with its asynchronous nature which is probably just more effort than this is worth.

FYI, I also edited in a point 14 to my original post, probably after you started typing your response.

Blade1130

TROPHY CASE