build(deps): bump bitovi/github-actions-storybook-to-github-pages from 1.0.3 to 1.0.4#440
Conversation
78e6998 to
a2e9a1a
Compare
| @@ -1,70 +1,70 @@ | |||
| import type { StorybookConfig } from '@storybook/react-vite'; | |||
There was a problem hiding this comment.
What: The import from @storybook/react-webpack5 is still included in the commented section but not used in the code. If the webpack5 configuration is no longer needed, consider removing or documenting it clearly.
Why: Properly cleaning unused code helps reduce confusion for developers who might look at this file in the future and ensures that the code remains clean and maintainable.
How: Either remove the commented line entirely if it's not needed, or add a comment explaining why it’s left there. If it's a legacy comment for reference, that should be stated.
| }); | ||
| }, | ||
| }; | ||
| export default config; |
There was a problem hiding this comment.
What: In the viteFinal for merging configurations, ensure that all paths used in the alias configuration are absolutely correct and dynamically resolved as needed.
Why: Incorrect paths can lead to errors or improper builds during storybook configurations, which can waste development time in debugging.
How: Double-check the paths being set in the alias mappings to ensure that they accurately correspond to their actual locations in the project structure.
| '@': path.resolve(__dirname, '..', 'src'), | ||
| }, | ||
| }, | ||
| }); |
There was a problem hiding this comment.
What: Consider adding an error handling mechanism in the viteFinal merging process to capture any potential issues during the merge operation.
Why: Error handling is crucial to provide clarity on what went wrong during the configuration step when running Storybook, making troubleshooting easier.
How: You can wrap the mergeConfig function call within a try-catch block to log errors or provide feedback when the merge fails.
| date: /Date$/i, | ||
| }, | ||
| }, | ||
| // Disable color contrast checks for the entire storybook. |
There was a problem hiding this comment.
What: Using inline styles such as [&_*]:[font-family:Figtree,sans-serif] in the JSX could lead to unintended style conflicts in some cases.
Why: This approach can lead to difficulties in debugging styles due to the complexity of the selectors, and might not work as intended if other styles are applied to the same elements. This could cause further maintainability issues as your project grows.
How: Consider defining your styles in a CSS file or using a CSS-in-JS solution that scopes styles more predictably. This will improve the maintainability and clarity of your styles.
| @@ -1,30 +1,30 @@ | |||
| import React from 'react'; | |||
There was a problem hiding this comment.
What: The renaming and restructuring of imports and declarations introduces unnecessary diff complexity without apparent functional changes.
Why: This could make it harder for other developers to quickly review what has changed in this PR, especially when the changes appear to be mostly cosmetic. Keeping the most significant functional changes clearly visible can help improve readability and understanding during reviews.
How: If the changes are only about alignment or style, consider separating these changes into a distinct PR focused solely on code cleaning, allowing functional changes to stand out.
| (Story) => ( | ||
| <div className="[&_*]:[font-family:Figtree,sans-serif] [&_*]:box-border"> | ||
| <Story /> | ||
| </div> |
There was a problem hiding this comment.
What: Disabling color contrast checks for the entire storybook may have accessibility implications and should be avoided wherever possible.
Why: Neglecting accessibility checks can lead to UI implementations that are not usable by all individuals, including those with visual impairments. Ensuring that color contrasts are sufficient improves usability and compliance with accessibility standards.
How: Consider leaving the accessibility guidelines enabled and using specific overrides only for problematic cases. Review your components to ensure that they comply with basic accessibility requirements.
| @@ -1,30 +1,30 @@ | |||
| const { getStoryContext } = require('@storybook/test-runner'); | |||
There was a problem hiding this comment.
What: The use of optional chaining (?.) could lead to unexpected behaviors if not carefully managed, especially in an asynchronous context.
Why: While optional chaining is helpful for avoiding errors when accessing properties of potentially undefined objects, it can also obscure bugs that arise from misconfigured parameters or missing data.
How: Consider validating the configuration objects and their structure before using optional chaining. This ensures that your code is robust and you have meaningful error handling in place.
| async postVisit(page, context) { | ||
| // Get the entire context of a story, including parameters, args, argTypes, etc. | ||
| const storyContext = await getStoryContext(page, context); | ||
| // Apply story-level a11y rules |
There was a problem hiding this comment.
What: Ensure that the accessibility tests are appropriately configured and that the parameters passed do not introduce security risks or performance bottlenecks.
Why: Misconfiguration of accessibility tests could lead to overlooking important accessibility issues, or adding unnecessary overhead that slows down the testing process.
How: Review the accessibility configuration being loaded into the Axe library and ensure tests are scoped correctly. Additionally, avoid executing tests on elements that could introduce performance issues due to excessive complexity.
| storyContext.parameters?.a11y?.element ?? '#storybook-root'; | ||
| await checkA11y(page, element, { | ||
| detailedReport: true, | ||
| detailedReportOptions: { |
There was a problem hiding this comment.
What: Consider discussing with your team whether the detailed report options should be enabled or disabled based on specific testing scenarios.
Why: Generating detailed reports can significantly increase the amount of data processed, potentially slowing down the tests or consuming unnecessary resources.
How: Evaluate your needs for accessibility reporting. If detailed reports are mostly unnecessary for certain tests, consider making this a configurable option instead of hardcoding it.
Bumps bitovi/github-actions-storybook-to-github-pages from 1.0.3 to 1.0.4.
Commits
ddd9d35Bump README versiondf206bdPin actions by SHA (#19)f1b2d57Merge pull request #12 from bitovi/add-video-linka2670cbAdd video demo!32b0c0aFix README.md examples versionDependabot 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)