feat(material/schematics): v15 migrate import declarations

[wagnermaciel]

• implement import declaration migrations for
  v15 legacy components ng-update

[devversion]

OOC: Why do we need to handle everything through captured updates, sorted by indices, if we could directly apply the updates? The original file indices are usable and that is what we use in all other migrations: https://github.com/angular/angular-cli/blob/3884b865262c1ffa5652ac0f4d67bbf59087f453/packages/angular_devkit/schematics/src/utility/update-buffer.ts#L330

just mentioning this for additional information. I guess my concern is that this is now a material schematics utilities folder but the concept of update objects is untypical

[wagnermaciel]

Directly applying the updates could cause problems with collisions, so capturing everything as updates avoids this issue altogether

E.g.

Given the following scenario, if the import was updated first, the stored position of the console.log would be stale. Contrarily, if the export name MatButton was renamed before the module specifier @angular/... was changed, the stored position of the module specifier would be stale

some-file.ts (before)

import {MatButton} from '@angular/material/button';
...
console.log(MatButton);

some-file.ts (after)

import {MatLegacyButton} from '@angular/material/legacy-button';
...
console.log(MatLegacyButton);

[devversion]

@wagnermaciel that's exactly it. If you would always only analyze the original source file and migrate on top of that, the original indices will remain known to the update recorder and the devkit update recorder/magic-string could perform all the replacements, even though if offsets would be shifted around.

[wagnermaciel]

I'm a little bit confused, but it seems like you're saying the devkit update recorder/magic-string already solves this problem in a standardized way? I've never tried using it, but from what I see here it looks promising

https://github.com/angular/angular-cli/blob/3884b865262c1ffa5652ac0f4d67bbf59087f453/packages/angular_devkit/schematics/src/utility/update-buffer_spec.ts#L335

I'll give it a shot and re-request review once I'm done

[devversion]

yeah, feel free to land this for now, but I'm just trying to avoid these common schematics utilities as all other migrations never required this. The magic string/update-recorder really handles this "magically". This is also why the insert left and insert right methods exist -- trying to keep original indices as is -- and placing stuff in between without shifting offsets known to the recorder. Magic string has a good readme IIRC

[wagnermaciel]

Took a step back here and started working from the v15 legacy-components ng-update migration side of things. I'll revisit sharing code with the v15 mdc-migration ng-generate migration through a migration-utilities later

[devversion]

Nice, LGTM. Pretty easy now with directly using the update recorder right? 😄

[wagnermaciel]

Nice, LGTM. Pretty easy now with directly using the update recorder right? 😄

Yeah, ty for the advice! 👍🏽

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}