Core: Add error categorization framework

[yannbf]

Closes #23511

What I did

This PR proposes a new way to write and throw errors in Storybook.

For more details, please check the README included in this PR.

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

• 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.

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

🦋 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>

[kylegach]

I only reviewed the README, but I'm loving this work! Great job, Yann! 👏

[kasperpeulen]

I'm thinking that this category should not be a field of StorybookError, but should be should be passed to telemetry at the point where the error is caught.

For example, a function such as readConfig from @storybook/csf-tools will throw all kind of errors, but we likely want to know in telemetry more about the context where this function is called. As it can be called in codemods, the eslint-plugin, build, init, dev etc.

Also, I'm kind of thinking that the boolean telemetry should not be part of the StorybookError class, but is something that is also context dependent. As for example, I don't think we might not want to send telemetry for the eslint plugin, as it can be used independent of storybook (for other integrations)?

Maybe we should just maintain a list of code's that we want telemetry for?

I guess you could say that telemetry is just a different concern all together than throwing errors. For example, when you use composeStories outside of storybook, or when used by other integrators, it is kind of weird that the Error that we throw contains a telemetry boolean.

[socket-security]

Removed dependencies detected. Learn more about Socket for GitHub ↗︎

🚮 Removed packages: telejson@7.1.0