feat(migrations): Adds support for CommonModule to standalone migration

[SkyZeroZx]

Common to Standalone Migration

This migration replaces CommonModule imports with specific standalone imports from @angular/common.

Usage

ng g @angular/core:common-to-standalone --path src/app/feature

Example

Before:

import { Component } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-example',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div *ngIf="show">
      {{ data | async | json }}
    </div>
  `
})
export class ExampleComponent {
  show = true;
  data = Promise.resolve({ message: 'Hello' });
}

After:

import { Component } from '@angular/core';
import { AsyncPipe, JsonPipe, NgIf } from '@angular/common';

@Component({
  selector: 'app-example',
  standalone: true,
  imports: [AsyncPipe, JsonPipe, NgIf],
  template: `
    <div *ngIf="show">
      {{ data | async | json }}
    </div>
  `
})
export class ExampleComponent {
  show = true;
  data = Promise.resolve({ message: 'Hello' });
}

Benefits

• Smaller bundle size: Only imports needed directives and pipes instead of the entire CommonModule
• Better tree-shaking: Unused parts of @angular/common are eliminated

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.dev application / infrastructure changes
• Other... Please describe:

What is the current behavior?

Issue Number: #60808

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[JeanMeche]

Thanks for this.
Can you make sure to include the corresponding docs in the change, see adev/src/content/reference/migrations/overview.md

[SkyZeroZx]

Thanks for this. Can you make sure to include the corresponding docs in the change, see adev/src/content/reference/migrations/overview.md

If I do it, I would first like to have your approval to be able to add it. I will do it on this same PR.

[JeanMeche]

Yes this is an optional migration that we'd like to have !

[SkyZeroZx]

Updated addressing the feedback, the only remaining question is whether to support NgModules or only standalone components. If it’s possible to consult this in some way, that would be great.

[JeanMeche]

Next round of comments. PTAL.

[JeanMeche]

This is me thinking out loud:

I think this is unsafe if we hit a @Directive(), ie with 0 arguments. iirc ts.isObjectLiteralExpression(config) will throw if config is undefined.

But since we don't care about Directive decorator, we should only check component decorators.

Either way, we need to make the check more robust.

[SkyZeroZx]

Since we only process the Component decorator, this shouldn't happen. However, it could be "possible" that a user might have something strange with the decorator. I'm going to add a condition.

private analyzeClass(
    node: ts.ClassDeclaration,
    typeChecker: ts.TypeChecker,
  ): CommonModuleReference | null {
    const nodeDecorators = ts.getDecorators(node);
    if (!nodeDecorators) return null;

    const decorators = getAngularDecorators(typeChecker, nodeDecorators);

    // Only process Component decorators, not Directive or other Angular decorators
    for (const decorator of decorators) {
      if (decorator.name === 'Component') {
        return this.analyzeComponentDecorator(node, decorator, typeChecker);
      }
    }

    return null;
  }

[JeanMeche]

Can you please rebase.

[SkyZeroZx]

Updated

[AndrewKushnir]

This PR was merged into the repository. The changes were merged into the following branches:

• main: 75fc16b

[melroy89]

Wait..? This is something else then ng generate @angular/core:standalone?

EDIT: Ah yes so this will get rid of the old CommonModule. But should ng generate @angular/core:standalone also not use CommonModule anymore..?

[JeanMeche]

ng generate @angular/core:standalone will transform your NgModules into standalone components (and delete some of your NgModules). This migration here will replace direct imports of the CommonModule into individual imports.

Those migrations are distinct and this one was introduced to help project follow the recommendations closely.