clean previous ngcc ivy entrpoints works when running ng update

[elvisbegovic]

🚀 Feature request

Command

• serve
• update

Description

Actually updating a project with ng update is not straightforward, if an update exist it update package.json versions and run npm i correctly. But now running ng serve always throw this known error:

ERROR in The ngcc compiler has changed since the last ngcc build.
Please remove "C:/Users/e.../ngcc-has-changed/node_modules" and try again.

Here we realize we need again remove node_modules and rerun npm i
This task is long and not automatic, or something escapes me?

Repro

Following my repro project which has fixed ng version to 9.0.0-rc.9

1. run git clone https://github.com/elvisbegovic/ngcc-has-changed.git && cd ngcc-has-changed && npm i && ng s
2. kill ng s with Ctrl+C
3. run ng update --next @angular/cli @angular/core --allow-dirty && ng s
4. error thrown

Describe the solution you'd like

Clean previous ngcc ivy entrypoints works in node_modules during ng update command, so they could be again compiled when rerun ng s after update finish.

[petebacondarwin]

npm does not reinstall previously installed packages if it works out that you are only adding a new package. (Note that yarn appears to wipe out the whole node_modules in any case).

Therefore you end up with a situation where @angular/compiler-cli has changed (and so the ngcc version) but there might be packages that ngcc modified that have not been re-installed, and so still contain code that was compiled by an older version of ngcc.

It is not trivial to "clean" out the previous ngcc compilation artifacts, and we decided it is simpler to wipe out the whole of node_modules and start again fresh.

Perhaps an idea would be for a tool to look through node_modules and delete any packages that were processed by a previous version of ngcc. Then when npm i is run, it will reinstall those packages cleanly...?

[dgp1130]

Discussed this in the CLI triage meeting (thanks for joining @petebacondarwin!). It seems like it is possible to fix this in ngcc and a few options came up.

ngcc could restore backup files when this case is detected. The tricky part here is that a node_module packages will have an unknown depth of *.d.ts files. We could either generate a manifest at compile-time, listing the files altered and then revert them to the back ups when necessary.

Alternatively, we could name the files with some special convention (such as adding a __ivy suffix) and then revert all files matching that convention.

The CLI could potentially wipe out node_modules/ in this case and reinstall, however this problem can also occur when users npm install or npm upgrade and the version of @angular/cli changes. We can't automatically fix the problem in those cases.

@petebacondarwin offered to look into this more.

[petebacondarwin]

Tracking via FW-1812

[petebacondarwin]

It turns out that we already name our back up files with an uncommon extension so it should be straightforward to identify and revert them: __ivy_ngcc_bak.

[petebacondarwin]

PR here #35079