build(deps): bump softprops/action-gh-release from 2 to 3#443
build(deps): bump softprops/action-gh-release from 2 to 3#443dependabot[bot] wants to merge 1 commit into
Conversation
6d3e149 to
f11f335
Compare
| @@ -1,70 +1,70 @@ | |||
| import type { StorybookConfig } from '@storybook/react-vite'; | |||
There was a problem hiding this comment.
What: Ensure that the import statement for path and StorybookConfig stays consistent through versions. It would be good to check the Storybook documentation to verify that nothing has changed in how these are imported or utilized.
Why: Changes between versions of Storybook could introduce new breaking changes or deprecations that may not be documented extensively in user-facing documentation, potentially leading to runtime errors or misconfigurations.
How: Refer to the latest Storybook documentation or the changelog for breaking changes in imports when upgrading from version 2 to version 3.
| import type { StorybookConfig } from '@storybook/react-vite'; | ||
| import path from 'path'; | ||
|
|
||
| /** @type { import('@storybook/react-webpack5').StorybookConfig } */ |
There was a problem hiding this comment.
What: The core.builder is set to '@storybook/builder-vite'. Make sure this is properly set in accordance with the desired build tool and configuration, as incorrect configuration could lead to build failures.
Why: Using the appropriate builder is essential for the smooth functioning of Storybook. If the wrong builder is selected, it might not work well with existing stories or could lead to compilation errors.
How: Verify if '@storybook/builder-vite' is the recommended or required builder for your setup in the current version of Storybook you are using, and cross-reference the compatibility with any necessary plugins.
|
|
||
| /** @type { import('@storybook/react-webpack5').StorybookConfig } */ | ||
| const config: StorybookConfig = { | ||
| stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|mjs|ts|tsx)'], |
There was a problem hiding this comment.
What: In the viteFinal function, you are removing the 'vite:dts' plugin. Make sure that this does not adversely affect any TypeScript definition generation that may be required for the stories and components you are working with.
Why: This could potentially break TypeScript support for auto-completion in your Storybook environment if definitions are not being generated correctly. Missing type definitions can lead to an incomplete or faulty development experience.
How: If you don't need this plugin, it's safe to remove, but make sure to test thoroughly to ensure type definitions are still being picked up accurately. Validate the TypeScript settings in your project.
| options: { | ||
| builder: { | ||
| viteConfigPath: path.resolve(__dirname, '..', 'vite.config.ts'), | ||
| }, |
There was a problem hiding this comment.
What: Review the changes in the alias configuration. Ensure that all paths correspond correctly to the new directory structure and that there are no misspellings or non-existing paths that could lead to import errors.
Why: Incorrect alias configurations could cause import failures in the components and utility modules across the application, preventing it from building or running correctly.
How: Check the paths defined in the alias section against your project directory structure, and make sure that the aliases point to the correct modules.
| // Disable color contrast checks for the entire storybook. | ||
| a11y: { | ||
| config: { | ||
| rules: [{ id: 'color-contrast', enabled: false }], |
There was a problem hiding this comment.
What: Consider enabling color contrast checks in accessibility settings.
Why: Disabling a11y checks might lead to accessibility issues for users with visual impairments. Color contrast checks are important to ensure readable text against background colors.
How: Instead of disabling the color-contrast rule, evaluate if you can achieve the desired design while maintaining sufficient contrast. If necessary, implement an exception only for specific cases rather than disabling it globally.
| decorators: [ | ||
| (Story) => ( | ||
| <div className="[&_*]:[font-family:Figtree,sans-serif] [&_*]:box-border"> | ||
| <Story /> |
There was a problem hiding this comment.
What: Ensure the typography classes applied here are explicitly defined in your Tailwind CSS configuration.
Why: Custom fonts like Figtree may not be included in the default Tailwind setup, leading to unexpected results if not properly configured. This could affect visual consistency across your application.
How: Verify that Figtree is added in the fonts section of your Tailwind CSS configuration files. If it is a custom font, make sure you've included it as per the best practices outlined in the Tailwind CSS documentation.
| <div className="[&_*]:[font-family:Figtree,sans-serif] [&_*]:box-border"> | ||
| <Story /> | ||
| </div> | ||
| ), |
There was a problem hiding this comment.
What: Refactor the presentation of decorators to improve readability and facilitate future changes.
Why: Using arrow functions within decorators makes the code slightly more challenging to maintain, especially when more complexity is added later. This can affect performance and readability.
How: Consider moving the inline functionality to a separate component for better organization, especially if there are more complex behaviors to be added to the story decorators.
| @@ -1,30 +1,30 @@ | |||
| const { getStoryContext } = require('@storybook/test-runner'); | |||
There was a problem hiding this comment.
What: Avoid using optional chaining in this context if compatibility is a concern.
Why: Using optional chaining (?.) can lead to unexpected behaviors in environments that don't fully support ES2020 features. If your CI/CD environments or browser support policies don't align with using this syntax, it could lead to runtime errors.
How: Consider adding fallbacks or validations before accessing these properties. You could check if storyContext.parameters exists before trying to access its properties.
| }, | ||
| }); | ||
| }, | ||
| }; |
There was a problem hiding this comment.
What: Inconsistent error handling if an a11y check fails.
Why: Currently, the code proceeds without any error handling on the checkA11y method. If accessibility checks encounter issues, it may obscure the tests' outcomes. Without clear feedback, future maintenance could become problematic.
How: Consider implementing a try-catch block around the checkA11y call. You can log errors or throw an error with detailed information about the accessibility check failure.
Bumps softprops/action-gh-release from 2 to 3.
Changelog
Sourced from softprops/action-gh-release's changelog.
Commits
b430933release: cut v3.0.0 for Node 24 upgrade (#670)c2e35e0chore(deps): bump the npm group across 1 directory with 7 updates (#783)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)