Core: Move @types packages to dev deps in core-common

[kyletsang]

Part of #24873

What I did

Moves all @types packages into dev dependencies. None of the types from the mentioned packages are exposed as part of the lib, so they don't need to be in regular deps list.

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

1. Build a local package
2. Install it into a test storybook with some default stories. I used npx storybook@next init
3. Ensure it runs with no issues

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>

[ndelangen]

None of the types from the mentioned packages are exposed as part of the lib

How do you know?

The runtime implementations are normal dependencies too, so they could be exposed.

It's easy for a future change to start exposing them, and then it's easy to forget to move to a regular dependency again, because there's little to no verification mechanism, other then users telling us they are experiencing errors.

I'm not convinced the pros outweight the cons, here.

[kyletsang]

None of the types from the mentioned packages are exposed as part of the lib

How do you know?

The runtime implementations are normal dependencies too, so they could be exposed.

It's easy for a future change to start exposing them, and then it's easy to forget to move to a regular dependency again, because there's little to no verification mechanism, other then users telling us they are experiencing errors.

I'm not convinced the pros outweight the cons, here.

I manually checked each of the moved @types packages and saw that none of the library-specific types were exposed. For example when using node-fetch, the function uses it internally, but only returns a boolean to the caller.

I do agree that this can change at anytime though. So perhaps for #24873, I can limit the changes to node-fetch to fix that error and revert the others.

Let me know what you think.

Thanks!

[ndelangen]

Wow, I did not realize you check them all. Thanks for being so thorough @kyletsang ❤️

I think I'll proceed with this PR then.