Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/54888/

The angular error is caused by the caching changes, and not by the changes in babel-core to traverse the Program node with the existing parent path.

Ohh :/

The problem is caused by using an old version of @babel/core with newer versions of @babel/traverse, since older versions of Babel core obviously do not have the changes in packages/babel-core/src/transformation/index.ts. And angular pins @babel/core to 7.22.5.

@alan-agius4 regardless of this bug on our side, what is the reason for pinning @babel/core, given that all its internal dependencies can get updated? In theory it should not cause problems because we aim at having every new version compatible with all the combinations of older versions of other packages, but in practice allowing @babel/core to upgrade together with the other Babel packages makes it less likely to find compatibility problems.

This should fix the compat problem, tested locally. Let's see if it fixes the angular-cli integration test.

The fix/check is very bad, but it's self-contained and designed to run as less as possible (it only runs when calling into @babel/traverse through one of the methods used by @babel/core, and only when those methods are not called recursively via @babel/traverse).

In general we pin all of our direct dependencies to have a more stable releases. By pinning all of our dependencies we reduce compatibility issues, bugs and other breaky behaviour as some packages don’t follow semver. Over the years this did prove to make the Angular CLI more stable especially for LTS versions.

However, in this case though pinning did cause a problem.

This is ready for review, but the code is incredibly ugly.

Performance wise it's ok: the new Error().stack check to see if our caller is @babel/core only happens once (per compiled file) when calling @babel/traverse from old versions of @babel/core or from programs using @babel/traverse directly.

The angular-cli (breaking) test is failing because the workaround only applies to Babel 7, but it will start passing once @angular/cli updates their @babel/core version.

Could we possibly make it only land in babel8?
The method based on stack detection doesn't seem very elegant, especially if someone disabled the stack.
This bug has been around for ages, and it should be acceptable to defer to babel8. Even I worry that someone is relying on the wrong behavior. 🤦‍♂️

I updated the PR to only land the breaking change in Babel 8.