Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core: Add an option to disable warnOnIncompatibleAddons #24663

Conversation

taozhou-glean
Copy link
Contributor

@taozhou-glean taozhou-glean commented Nov 1, 2023

Closes #23846

What I did

adding an option to turn off warnOnIncompatibleAddons, this does not fix the issue in #23846 but does provide a workaround other than patching storybook.

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

did not find existing test case for new feature flags, let me know if I need to test it somehow.

Manual testing

This section is mandatory for all contributions. If you believe no manual test is necessary, please state so explicitly. Thanks!

checked with local repo that has incompatible addons

Documentation

not sure if it should be documented anywhere, seems no for warnOnLegacyHierarchySeparator, so keep it in code only for now.

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

@taozhou-glean taozhou-glean marked this pull request as ready for review November 1, 2023 23:56
@ndelangen ndelangen self-assigned this Nov 2, 2023
@ndelangen ndelangen changed the title core-server: add an option to disable warnOnIncompatibleAddons Core: Add an option to disable warnOnIncompatibleAddons Nov 2, 2023
@taozhou-glean taozhou-glean force-pushed the tao-disable-warnOnIncompatibleAddons branch from 558510a to c6f0be4 Compare November 2, 2023 18:05
@kasperpeulen
Copy link
Contributor

@shilman WDYT about this? It LGTM

@@ -6,6 +6,10 @@ import dedent from 'ts-dedent';
import { getIncompatibleAddons } from '../../../cli/src/automigrate/helpers/getIncompatibleAddons';

export const warnOnIncompatibleAddons = async (config: StorybookConfig) => {
if (config.features?.warnOnIncompatibleAddons === false) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shilman I'm guessing warnOnIncompatibleAddons isn't temporary, so you'd want to locate it somewhere else?

Copy link
Member

@yannbf yannbf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @taozhou-glean thanks for the contribution. However I have a question:

@ndelangen @shilman why should there be such feature like this? We can gracefully handle the warnOnIncompatibleAddons function instead. If users have a broken experience because of an internal JsPackageManager issue, and later have to somehow figure out that they can set up a flag to disable it, it seems weird to me. If we just handle the error, it will work for everyone. This code path (though important for users migrating) isn't critical anyway.

@taozhou-glean
Copy link
Contributor Author

We can gracefully handle the warnOnIncompatibleAddons function instead.

that would be great!

@taozhou-glean
Copy link
Contributor Author

adding a try ... catch around warnOnIncompatibleAddons as you suggested in #24880, closing this one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: @storybook/core-server#7.3 does not work with bazel
4 participants