Storybook Angular + Compodoc with duplicate class names issue #32199
Replies: 1 comment
-
Hi @RobbyRabbitman! I'm Dosu and I’m helping the storybook team. This issue happens because production builds (via Angular's compiler, tsc, or Webpack) can change class names due to minification or optimizations, which breaks the exact class name matching that Storybook Angular's getComponentData relies on for Compodoc integration. There are currently no configuration options in Storybook, Angular, or Compodoc to preserve class names or to support fallback/pattern-based matching in getComponentData—matching is strictly by exact class name, so any change causes the lookup to fail see code. Workarounds: you could ensure unique class names across packages, or patch the compodoc output to align with the names used in production. For more flexibility, you could monkey-patch getComponentData or wrap it to implement your own fallback/pattern matching logic (e.g., try If this is a recurring pain point, it might be worth proposing a feature for user-configurable or pattern-based matching in Storybook Angular. For more context on related build issues and why disabling optimizations doesn't always help, see this relevant issue. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
We have Angular components that wrap web components - They are located in different packages but have same class names. The angular component imports the web package so that the web component is registered.
During development the component is found in the compodoc json but with the prod build its not, because the class name gets changed. Idk, what build tool (Webpack, tsc, angular compiler) causes that. I wonder if thats userland problem or maybe there is a configuration so that the angular class names are kept and the web components class names are changed or if the function getComponentData can be made a little more flexible like when exact matches are not found, than fall back to a
*_${name}
pattern . Or the user can specify the pattern, since in my case the name was constructedpackage-name_class-name
.Do you have any ideas?
Additional information
No response
Create a reproduction
No response
Beta Was this translation helpful? Give feedback.
All reactions