I was looking at this change and noticed a potential bug that will cause the Angular compiler to crash with a TypeError on valid template syntax.

In packages/compiler/src/template/pipeline/src/ingest.ts, the new logic assumes root.tagName is always a string:

const [, tagName] = splitNsName(root instanceof t.Element ? root.name : root.tagName!);

However, if a developer places a structural directive directly on an <ng-template> at the root of a control flow block, root.tagName is null. As documented in packages/compiler/src/render3/r3_ast.ts, tagName is explicitly set to null to distinguish synthetic templates from actual <ng-template> elements.

The Crash

Because of the non-null assertion (!), splitNsName(null) gets called. Inside splitNsName (in packages/compiler/src/ml_parser/tags.ts), it evaluates if (elementName[0] != ':'), throwing a TypeError: Cannot read properties of null (reading '0') and crashing the compiler.

Failing Test Case

Here is a test case (e.g. for packages/core/test/acceptance/control_flow_if_spec.ts) that demonstrates the crash during compilation:

it('should not crash the compiler when an @if block root is an ng-template with a structural directive', () => {
  @Component({
    selector: 'test-cmp',
    template: 'Main: <ng-content></ng-content> Slot: <ng-content select="svg"></ng-content>',
  })
  class TestComponent {}

  @Component({
    imports: [TestComponent, NgIf],
    template: `
      <test-cmp>
        @if (true) {
          <ng-template *ngIf="true">
            <svg><text>foo</text></svg>
          </ng-template>
        }
      </test-cmp>
    `,
  })
  class App {}

  // This will throw TypeError: Cannot read properties of null (reading '0')
  expect(() => TestBed.createComponent(App)).not.toThrow();
});

Suggested Fix

You might want to handle the null case gracefully before passing it to splitNsName, similar to how the old code handled it:

const rawTagName = root instanceof t.Element ? root.name : root.tagName;
const tagName = rawTagName ? splitNsName(rawTagName)[1] : null;

// Don't pass along `ng-template` tag name since it enables directive matching.
return tagName === NG_TEMPLATE_TAG_NAME ? null : tagName;

I was looking at this change and noticed a potential bug that will cause the Angular compiler to crash with a TypeError on valid template syntax.

In packages/compiler/src/template/pipeline/src/ingest.ts, the new logic assumes root.tagName is always a string:

const [, tagName] = splitNsName(root instanceof t.Element ? root.name : root.tagName!);

However, if a developer places a structural directive directly on an <ng-template> at the root of a control flow block, root.tagName is null. As documented in packages/compiler/src/render3/r3_ast.ts, tagName is explicitly set to null to distinguish synthetic templates from actual <ng-template> elements.

The Crash

Because of the non-null assertion (!), splitNsName(null) gets called. Inside splitNsName (in packages/compiler/src/ml_parser/tags.ts), it evaluates if (elementName[0] != ':'), throwing a TypeError: Cannot read properties of null (reading '0') and crashing the compiler.

Failing Test Case

Here is a test case (e.g. for packages/core/test/acceptance/control_flow_if_spec.ts) that demonstrates the crash during compilation:

it('should not crash the compiler when an @if block root is an ng-template with a structural directive', () => {
  @Component({
    selector: 'test-cmp',
    template: 'Main: <ng-content></ng-content> Slot: <ng-content select="svg"></ng-content>',
  })
  class TestComponent {}

  @Component({
    imports: [TestComponent, NgIf],
    template: `
      <test-cmp>
        @if (true) {
          <ng-template *ngIf="true">
            <svg><text>foo</text></svg>
          </ng-template>
        }
      </test-cmp>
    `,
  })
  class App {}

  // This will throw TypeError: Cannot read properties of null (reading '0')
  expect(() => TestBed.createComponent(App)).not.toThrow();
});

Suggested Fix

You might want to handle the null case gracefully before passing it to splitNsName, similar to how the old code handled it:

const rawTagName = root instanceof t.Element ? root.name : root.tagName;
const tagName = rawTagName ? splitNsName(rawTagName)[1] : null;

// Don't pass along `ng-template` tag name since it enables directive matching.
return tagName === NG_TEMPLATE_TAG_NAME ? null : tagName;

Thanks for checking! I don't think it can get there though. A template only becomes root when its tagName isn't null (the check in the loop over node.children a few lines above), so for <ng-template *ngIf> the function returns null before splitNsName is called, same as before this change. I ran your test case against this branch to be sure and it passes, and the block renders the same as before.

I was looking at this change and noticed a potential bug that will cause the Angular compiler to crash with a TypeError on valid template syntax.
In packages/compiler/src/template/pipeline/src/ingest.ts, the new logic assumes root.tagName is always a string:

const [, tagName] = splitNsName(root instanceof t.Element ? root.name : root.tagName!);

However, if a developer places a structural directive directly on an <ng-template> at the root of a control flow block, root.tagName is null. As documented in packages/compiler/src/render3/r3_ast.ts, tagName is explicitly set to null to distinguish synthetic templates from actual <ng-template> elements.

The Crash

Because of the non-null assertion (!), splitNsName(null) gets called. Inside splitNsName (in packages/compiler/src/ml_parser/tags.ts), it evaluates if (elementName[0] != ':'), throwing a TypeError: Cannot read properties of null (reading '0') and crashing the compiler.

Failing Test Case

Here is a test case (e.g. for packages/core/test/acceptance/control_flow_if_spec.ts) that demonstrates the crash during compilation:

it('should not crash the compiler when an @if block root is an ng-template with a structural directive', () => {
  @Component({
    selector: 'test-cmp',
    template: 'Main: <ng-content></ng-content> Slot: <ng-content select="svg"></ng-content>',
  })
  class TestComponent {}

  @Component({
    imports: [TestComponent, NgIf],
    template: `
      <test-cmp>
        @if (true) {
          <ng-template *ngIf="true">
            <svg><text>foo</text></svg>
          </ng-template>
        }
      </test-cmp>
    `,
  })
  class App {}

  // This will throw TypeError: Cannot read properties of null (reading '0')
  expect(() => TestBed.createComponent(App)).not.toThrow();
});

Suggested Fix

You might want to handle the null case gracefully before passing it to splitNsName, similar to how the old code handled it:

const rawTagName = root instanceof t.Element ? root.name : root.tagName;
const tagName = rawTagName ? splitNsName(rawTagName)[1] : null;

// Don't pass along `ng-template` tag name since it enables directive matching.
return tagName === NG_TEMPLATE_TAG_NAME ? null : tagName;

Thanks for checking! I don't think it can get there though. A template only becomes root when its tagName isn't null (the check in the loop over node.children a few lines above), so for <ng-template *ngIf> the function returns null before splitNsName is called, same as before this change. I ran your test case against this branch to be sure and it passes, and the block renders the same as before.

Pushed your version anyway, it reads better without the non-null assertion and doesn't depend on the check in the loop.