@atscott I just met the same situation recently as described in the issue, I've updated commit description.

  @if (activeClass) {
    <a [routerLink]="href" [routerLinkActive]="activeClass"
       [routerLinkActiveOptions]="activeOptions"
       [ariaCurrentWhenActive]="ariaCurrent">
      <ng-content />
    </a>
  } @else {
    <a [routerLink]="href"><ng-content /></a>
  }

that’s not really true is it? Why not this:

    <a [routerLink]="href" [routerLinkActive]="activeClass ?? []"
       [routerLinkActiveOptions]="activeOptions ?? {}"
       [ariaCurrentWhenActive]="ariaCurrent">
      <ng-content />
    </a>

That seems like quite a small thing to have to do.

@atscott I have also updated the code with a return-guard in update().

1. routerLink already treats null as “turn this off”

routerLink explicitly treats null/undefined as a way to disable the directive:

// null|undefined: effectively disables the routerLink
set routerLink(commandsOrUrlTree: readonly any[] | string | UrlTree | null | undefined) {
  if (commandsOrUrlTree == null) {
    this.routerLinkInput.set(null);
    ...
  }
}

routerLinkActive is typically used alongside routerLink on the same element, so it’s natural to expect the same behavior. Using null to mean “opt out” is already the established pattern here. Having routerLinkActive behave differently creates an unnecessary inconsistency.

2. ?? [] and ?? {} aren’t real substitutes

The common workaround (activeClass ?? [] or activeOptions ?? {}) doesn’t actually disable the directive:

• activeClass ?? [] passes an empty array. The directive still subscribes to router events, runs matching logic, and triggers updates — it just doesn’t apply classes.
• activeOptions ?? {} passes an actual object, not “no options”. An empty object is still a value with meaning, not the absence of intent.

Using null clearly expresses “I don’t want this active,” whereas [] or {} still activates the directive with a specific behavior.

3. Strict template type-checking makes this worse

With strict inputs enabled, a component input like:

@Input() activeClass: string | null;

won’t work with:

<a [routerLinkActive]="activeClass">

Every consumer now has to remember to write activeClass ?? [] everywhere. That pushes the burden onto the caller instead of handling it once inside the directive.

Summary

The ?? workaround technically works, but it:

• Forces every caller to work around the same limitation
• Keeps the directive running even when it shouldn’t
• Introduces tricky issues with content projection in wrapper components
• Breaks consistency with how routerLink already behaves

Letting routerLinkActive accept null would be a cleaner, more intuitive API and would match the behavior developers already expect from routerLink.

Angular directives broadly accept null | undefined on inputs to mean "this input is not set". routerLink does it. ngClass does it. ngStyle does it. This is not a new pattern — it's the established contract for optional inputs across the framework. routerLinkActive should be consistent with that, not an exception.

Woah, looks like you've opened a lot of issues/PRs recently. While we appreciate contributions from the community, triaging and reviewing a large influx of content in a short time period takes time away from other ongoing projects. As a result, we're closing these issues/PRs to maintain the team's focus.

Note that this is not necessarily a rejection of the goals or direction of any of these contributions in particular, so much as a reflection of the team's current capacity and priorities.

You are welcome to open a smaller subset of issues/PRs in accordance with our policy focused on the most important and impactful contributions and we will do our best to prioritize a response as soon as possible.