bug(migrations): Angular 20 update migrations stripping BOM from UTF8 files that have them

[hamfastgamgee]

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

The Angular 20 migration for Material (presumably the one that fixes variable names) is changing files of various types (TS, CSS, HTML, and SCSS) en masse from UTF-8 to Windows-1252 encoding on Windows, even if there is otherwise nothing at all to replace in those files. I found bug #27057 which appears to be about a related problem in the old MDC migration,

Reproduction

Steps to reproduce:

1. Migrate an existing Angular Material app on Windows to Angular 20 using "ng update".
2. Um, why are we touching most of the files and changing their encodings?

Expected Behavior

If the migration has nothing to do to a file, it should do nothing to that file. And if it does happen to need to change a file for the variable token replacements, it shouldn't switch that file's encoding.

Actual Behavior

Dozens of files in my tree with no substantive changes but with encoding switched from UTF-8 to Windows-1252.

Environment

• Angular:
  Angular CLI: 20.0.0
  Node: 22.14.0
  Package Manager: npm 11.3.0
  OS: win32 x64

Angular: 20.0.0
... animations, build, cli, common, compiler, compiler-cli, core
... forms, platform-browser, router

Package Version

@angular-devkit/architect 0.2000.0
@angular-devkit/core 20.0.0 (cli-only)
@angular-devkit/schematics 20.0.0
@angular/cdk 20.0.1
@angular/material 20.0.1
@schematics/angular 20.0.0
ng-packagr 20.0.0
rxjs 7.8.2
typescript 5.8.3
zone.js 0.15.1

• Operating System (e.g. Windows, macOS, Ubuntu): Windows 11

[hamfastgamgee]

Possibly related to (or maybe the same as?) #31259

[hamfastgamgee]

It doesn't look like it actually modifies the file contents and a bunch of IDEs still say it's UTF-8, but git recognizes the file as "different" somehow and Azure DevOps says it changes encodings from UTF-8 to Windows-1252. But in several text editors that can work with both formats, if I convert back and forth between the formats after this happens, git sees no difference and I can't reset it. Ugh.

In any case, my guess is that the schematic for renameMdcTokens should probably be checking whether the content actually changed prior to calling "overwrite" like the other schematic is.

[hamfastgamgee]

Okay, I ran a clean copy, and despite what the tooling says, I'm seeing that the files in question already had BOMs in them (I'm not sure how) and perhaps the migration is stripping those? I don't understand how so many files in my source repo are inconsistent on this front, and therefore my description of the issue may be slightly askew, but it does appear that the migration is mucking with content when it shouldn't be.

Okay, after further testing, I think Azure DevOps is lying to me about switching to Windows-1252, and what is happening is that the migration is stripping BOMs from UTF8 files that have them. That may actually be a net positive for my codebase, but it's probably not an intended outcome. :)

[crisbeto]

AFAIK we can't do much about the encoding since the CLI reads all the files for us. The rest is a duplicate of #31259.