Angular: Fix for monorepo setups

[valentinpalkovic]

Closes #14828

What I did

Problem: (See the explanation/findings here)

In monorepository setups, multiple projects or libraries share common dependencies. Sometimes, due to various configurations or linking strategies, these dependencies might get loaded more than once. This results in multiple distinct instances of the same library coexisting in the runtime.

When using the instanceof operator to check if an object is an instance of a particular constructor or class, JavaScript checks against a specific prototype/reference. If two versions (or instances) of a library are loaded in a monorepository, the prototype of a class from one instance is not the same as the prototype of the same class from another instance. This can cause the instanceof checks to fail even when, from a logical perspective, they shouldn’t.

In the context of our Angular decorators (like Component or Directive), the instanceof operator might give incorrect results if, for instance, one part of the monorepo references one instance/version of @angular/core and another part references a different instance. This can lead to situations where an object that logically is an instance of Component is not recognized as such by the instanceof check.

Solution:

To address this, we're moving away from using instanceof for type checks. Instead, we're leveraging Angular's internal property ngMetadataName, which is set on decorators like Component, Directive, etc., during the compilation phase. This property provides a string representation of the decorator's type, making it a reliable way to determine the type of decorator, irrespective of how many instances of @angular/core are loaded.

By implementing the isDecoratorInstanceOf function and using the ngMetadataName property, we can ensure consistent and accurate type checks across all projects in the monorepository, eliminating the quirks introduced by the instanceof operator in this specific context.

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

Manual testing not required

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>