[Bug]: Either Storybook 6 must work with Angular 16 or Storybook 7 must work with non-standalone components

[VictorienTardif]

Describe the bug

Storybook 6 is not compatible with Angular 16 as explained in this issue:
#22329

Storybook 7 is not compatible with non standalone components as explained in these issues:
#22323
#20855

How can we continue to use Storybook without refactoring all our components?
I feel stuck.

Migrating to standalone is not mandatory on Angular side so it should not be on Storybook neither imo.

To Reproduce

No response

System

No response

Additional context

No response

[mattlewis92]

As a workaround to using storybook 6 + angular 16 together, I found that if you set this in your .storybook/main.js config it prevents ngcc from trying to run and fixes the issue:

angularOptions: {
  enableIvy: false
},

[dszmaj]

As a workaround to using storybook 6 + angular 16 together, I found that if you set this in your .storybook/main.js config it prevents ngcc from trying to run and fixes the issue:

angularOptions: {
  enableIvy: false
},

this worked for Angular 16, but 16.1 introduced breaking changes in CLI so it crashes again

[harellevy]

this solution of enableIvy: false makes services that are providedIn: 'root' not be provided in the stories in my case.
I'm not using standalone components that often

[valentinpalkovic]

Hi @VictorienTardif

Thank you for reporting this issue. Could you provide an extensive reproduction, where you explain upon some examples why Storybook is not working with non-standalone components? Indeed, you can use standalone or non-standalone components in Storybook. You don't have to switch. What you have to do, though, is to adjust the way how app/environment-wide services are registered. Please follow the steps mentioned here https://github.com/storybookjs/storybook/tree/next/code/frameworks/angular#applicationconfig-decorator and make sure to follow the migration guide: https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#angular-application-providers-and-modulewithproviders

[github-actions]

Hi there! Thank you for opening this issue, but it has been marked as stale because we need more information to move forward. Could you please provide us with the requested reproduction or additional information that could help us better understand the problem? We'd love to resolve this issue, but we can't do it without your help!

[github-actions]

I'm afraid we need to close this issue for now, since we can't take any action without the requested reproduction or additional information. But please don't hesitate to open a new issue if the problem persists – we're always happy to help. Thanks so much for your understanding.

[Martinspire]

So what is the solution now that this story is marked as done? I haven't found any other solution since and after trying a couple of hours to get our project going, it just fails to be a workable solution with 7 and I don't see this changing with 8 either. If non-standalone is not supported, you will lose a lot of Angular projects that will move away...

[valentinpalkovic]

@Martinspire Unfortunately, nobody has answered my question in #22888 (comment). So could you provide a minimal reproduction where you elaborate on why non-standalone components are not supported?

[Martinspire]

I don't have an example just yet but I found out quickly that using routing or httpclient in the stories is very annoying to do right now since you can't just reuse stuff from your project as you can't just turn something that is coming from modules into a standalone solution. It would probably work fine the other way around. My first attempt to make a breadcrumbs example where my component listens to routing events was not working properly since the whole system isn't really designed for standalone just yet.

I also found that using components that rely on other modules give issues where the only solution would be that I make a new module where I declare that component with some dependencies and export it, but it would then always show an error that its part of two modules.

Standalone modules are a specific use case for angular that I don't see fit every project. Perhaps it will be the standard for Angular moving forward, but I fail to see the advantage for most projects regardless. Its nice for a UI library that other projects will rely on, but if you are the only user of said components, the benefit is non-existant and I don't think Storybook should dictate whether I use or not use standalone components. For me it becomes clear that Storybook is not fitting our requirements and would require too much work to rework our existing setup. Especially with how our project is structured and how modules depend on other modules and providers that currently work fine with Angular but not with Storybook. And also especially seeing how there's very little examples out there that use Storybook with Standalone modules for situations where you need Routers (both routerlinks and router-outlets), complex form elements, httpclient get requests and more.