Add preview type and update CLI template

[kasperpeulen]

Closes #20950

What I did

• export Preview from all renderers
• Update CLI templates

I didn't update the documentation yet, or added a runtime warning for old style preview.js files. Maybe we can outscope that for now?

How to test

1. Run a sandbox for template, e.g. yarn task --task sandbox --start-from auto --template react-vite/default-ts
2. Check the generated preview!
   -->

Checklist

• Make sure your changes are tested (stories and/or unit, integration, or end-to-end tests)
• Make sure to add/update documentation regarding your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Maintainers

• If this PR should be tested against many or all sandboxes,
  make sure to add the ci:merged or ci:daily GH label to it.
• Make sure this PR contains one of the labels below.

["cleanup", "BREAKING CHANGE", "feature request", "bug", "documentation", "maintenance", "dependencies", "other"]

[yannbf]

I think the end result should be like the other import?

import type { Preview } from \\"@storybook/angular\\"

[kasperpeulen]

Hm, maybe we should run prettier on it, using user config, if possible. The main.js template you wrote is actually using single quotes everywhere:

  if (isTypescript) {
    imports.push(`import type { StorybookConfig } from '${frameworkPackage}';`);
  } else {
    imports.push(`/** @type { import('${frameworkPackage}').StorybookConfig } */`);
  }

[kasperpeulen]

Prettified the files based on user config

[yannbf]

I wonder how this is going to work with community frameworks/renderers, it's better if the entire package comes as a parameter, rather than half of the import

[kasperpeulen]

I'm not sure as well. Do we have an community framework example that I could test?
@JReinhold Do you know more about this?

[kasperpeulen]

Fixed

[yannbf]

I'm quite curious regarding the types coming from renderers. Checking this PR it got me thinking that React users would have the same types experience if they're using @storybook/react-vite or @storybook/react-webpack, however they probably want different types if they're using @storybook/nextjs, given that Nextjs provides out of the box routing and other features that can be configured at the parameter level. Does this make sense? Or should we just do some sort of augmentation in the future for scenarios like this?

[kasperpeulen]

Does this make sense? Or should we just do some sort of augmentation in the future for scenarios like this?

@yannbf I think module augmentation would suffice:

declare module '@storybook/react' {
  interface Parameters
    extends StorybookParameters,
      ChromaticParameters,
      DocsParameters,
      NextjsParameters {}
}

I like that the csf files only import types from preview, and are kind of decoupled from the builder.

[yannbf]

Awesome stuff!!