export some types to avoid "not portable" error

[literalpie]

Fixes #24656

What I did

When Storybook React is used in a project with tsConfig values declaration: true and moduleResolution: bundler, you can get an error like the following:
inferred type of default cannot be named without a reference to [etc]/node_modules/@storybook/types . This is likely not portable. A type annotation is necessary.

To fix this error, I changed the code to export some types. I know you may not be eager to add things to the public API, so I prefixed the types with underscores.

In the attached issue, @kasperpeulen said

I think this issue is best solved by instructing people how to exclude *.stories.tsx from emitting d.ts, but still keep it being typechecked.

I know this would be better, but in my case, adding a second tsconfig to hundreds of packages so we can avoid emitting storybook types would more difficult than this fix. I understand if you don't want to merge it though 🙇🏼

Also note, I was unable to reproduce similar issues in other frameworks (angular and Vue). I believe this is only an issue in React because the react storybook types have some conditional types.

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

I was unable to reproduce this issue inside the storybook monorepo - I think because the way types are built is different from production builds. Here is a reproduction repo

1. In that repo, open src/Errors.stories.tsx
2. TS errors should be shown in your editor
3. You can also see the errors by running pnpm run build:types

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>

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 843179f. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 1 target

• nx run-many -t build -c production --parallel=3

---

Sent with 💌 from NxCloud.

[kasperpeulen]

I wonder what happens if you add @storybook/types to your dependencies @literalpie

[literalpie]

@kasperpeulen Adding @storybook/types to my dependencies in package.json doesn't fix the issue. It does help to add import {} from '@storybook/types' at the top of the file even if nothing is imported.

[kasperpeulen]

Can you share a https://storybook.new reproduction? Then I will play around a bit if we can do something less weird.

Some type wouldn't hurt to export such as PartialStoryFn. Maybe we should call it StoryFn though. cc @tmeasday

aybe we can restructure our code a bit, so that only exports are needed that we want to make public.

[literalpie]

I did my best to make a StackBlitz reproduction here, but it seems to behave differently than a repository cloned to my machine.

See Button.stories.ts for the error

[tmeasday]

Some type wouldn't hurt to export such as PartialStoryFn. Maybe we should call it StoryFn though. cc @tmeasday

As usual there are like many "story functions" that are similar but aren't exactly the same which makes naming hard and ambiguous.

What would a user expect the "story function" to be? The thing they write in their CSF file? The thing passed to a decorator? The thing passed to a renderToCanvas function?

They are all different. I don't know if the middle one (which is what a PartialStoryFn is) would be the one I'd call StoryFn. Perhaps a better name is DecoratorStoryFn.