Sorry for the noise if I'm wrong, but in #50063, some usages of global were replaced by globalThis because "global is now available on every runtime supported by Angular". Maybe globalThis could be used here, too?

Sorry for the noise if I'm wrong, but in #50063, some usages of global were replaced by globalThis because "global is now available on every runtime supported by Angular". Maybe globalThis could be used here, too?

@Yogu This is fine here, the global constant is typed as any. globalThis only has the cross-env global object/methods.

This has the potential of introducing issues for environments with multiple copies of Angular on a page, e.g. self-contained Angular elements.

@JoostK Good point! Do we have a test for this type of environments? I didn't see any, but it is nice to have as there are some usages of global in the codebase which might produce the same issue.

For this particular case I'm optimistic it may not cause issues since deps tracker uses the class as key to store Types and their info, and since classes from different environments are different there might not be a conflict ... in other words one depsTracker for all environments might work. But we can try it out and even add some tests for that if possible.

I don't know of any such scenarios being covered by tests. My main concern is how the code of the deps tracker itself might be different across versions, possibly resulting in failures.

I doubt that multiple copies/versions of @angular/core are widely used intentionally; we typically see the opposite problem where two copies have independent runtime state, resulting in e.g. inject throwing that no injection context is available, if the injection context is only active in one copy of the runtime, where inject of the other runtime is used.

I would like to understand how this module may end up being loaded twice unintentionally to better judge the changes in this PR, i.e. is this a "root cause" fix, or a workaround for an unknown cause.

The actual bug is that we are importing using relative imports from other entry-points. The bundler will then duplicate the code, even though it should actually be imported from e.g. @angular/core's primary entry-point. This is a problem we were also facing in Angular Material a while ago- and we built a tslint rule to prevent this.

We never ended up needing it here, but I've started work to build this into ng_package as that Bazel rule has all the necessary information and we can improve correctness here + fix singleton bugs like this. Those are always hard to debug and quite annoying.

Nice! Close in favour of #51500

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.}