build(deps): bump lodash and @microsoft/api-extractor#431
build(deps): bump lodash and @microsoft/api-extractor#431dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
dependencies
ManiruzzamanAkash
force-pushed
the
dependabot/npm_and_yarn/multi-4c254740be
branch
from
d181b02 to
a7885b1
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| @@ -1,16 +1,16 @@ | |||
| // Import the default config file and expose it in the project root. | |||
There was a problem hiding this comment.
What: The import statements and configuration are not changed and appear the same.
Why: These comments and configuration settings are crucial for maintaining consistency in code formatting across the project. The consistency is important in team environments and for project readability.
How: Consider maintaining a uniform commenting style or using a version control system to track changes, as changes here don't impact functionality but convey crucial intent.
| ]; | ||
|
|
||
| export default config; | ||
| // Import the default config file and expose it in the project root. |
There was a problem hiding this comment.
What: The changes do not introduce any functional changes, merely adjustments in formatting.
Why: While changes in formatting or style might align with your project's standards, make sure these are intentional and serve a purpose in enhancing readability. Ensure no functional alterations or unnecessary complexity are introduced through reformatting.
How: Continuing to evolve formatting rules should be aligned with the team's consensus. Ensure any such changes are justified within team discussions and aligned with previous coding standards.
| @@ -1,76 +1,76 @@ | |||
| // This file has been automatically migrated to valid ESM format by Storybook. | |||
There was a problem hiding this comment.
What: Consider reviewing the use of the @storybook/react-webpack5 type reference that is commented out in the code.
Why: The project has migrated to the ESM format and is using @storybook/react-vite, which means any type references from the previous configuration might be obsolete and could lead to confusion or misconfiguration going forward.
How: Remove the commented line that references the previous version if it is not needed for future reference or clarify its necessity.
| const __filename = fileURLToPath(import.meta.url); | ||
| const __dirname = dirname(__filename); | ||
There was a problem hiding this comment.
What: While merging default configuration with custom configurations using viteFinal, please ensure that there are no overlapping properties that could potentially lead to unexpected behavior during the build process.
Why: If properties overlap between the default and custom, it can lead to misconfiguration or runtime errors, affecting the performance and reliability of the Storybook instance.
How: Consider explicitly reviewing the merged properties against documentation or doing local testing as you proceed with the configuration to ensure expected results.
| '@chromatic-com/storybook', | ||
| '@storybook/addon-a11y', | ||
| '@storybook/addon-docs', | ||
| '@storybook/addon-mcp', |
There was a problem hiding this comment.
What: Double-check any vulnerable packages and ensure that all plugins meet the latest security practices, especially after upgrading dependencies.
Why: Given that you are updating several packages, it is important to mitigate any potential security vulnerabilities introduced through dependencies. Dependencies like vite, which handle various build tasks, can present security risks if configuration isn't aligned with best practices.
How: Verify each plugin against known vulnerabilities and assess their configurations based on the latest recommendations in their documentation.
| framework: { | ||
| name: '@storybook/react-vite', | ||
| options: { | ||
| builder: { |
There was a problem hiding this comment.
What: Consider explicitly defining types for various properties instead of relying on inferred types whenever possible.
Why: Explicit types improve readability and maintainability, making it clearer what each part of the configuration is expected to accept, and can help catch type-related errors early during development.
How: Wherever applicable, add TypeScript interfaces or types to ensure that the configuration is well-typed according to the needs of the project.
| @@ -1,5 +1,5 @@ | |||
| <style> | |||
There was a problem hiding this comment.
What: The style tag uses inconsistent line endings (both and ).
Why: Inconsistent line endings can lead to issues with cross-platform compatibility and may cause unnecessary diffs in version control. Standardizing line endings improves readability and maintainability of the code.
How: Ensure that the file consistently uses either Unix ( ) or Windows ( ) line endings throughout. Most projects adopt Unix-style line endings, so consider using that for consistency.
| font-family: 'Figtree', sans-serif; | ||
| } | ||
| </style> | ||
| <style> |
There was a problem hiding this comment.
What: The style block should include a comment explaining its purpose for clarity.
Why: Adding comments can help other developers (or your future self) understand the purpose of the styles and how they relate to the overall application. This enhances maintainability and onboarding for new developers.
How: Consider adding a comment like <!-- Set default font for the application --> above the style tag.
| }, | ||
| }, | ||
| // Disable color contrast checks for the entire storybook. | ||
| a11y: { |
There was a problem hiding this comment.
What: Consider reviewing why accessibility (a11y) checks are disabled.
Why: Disabling color contrast checks can lead to accessibility issues for users with visual impairments. It is critical to ensure that your application is usable for everyone, including those who may have trouble distinguishing colors.
How: Investigate the reasoning for disabling the 'color-contrast' rule. If the styling has been thoroughly reviewed and ensures legibility and contrast, document that reasoning. Otherwise, consider enabling the check or implementing improvements to enhance accessibility.
| }, | ||
| }, | ||
| // Disable color contrast checks for the entire storybook. | ||
| a11y: { |
There was a problem hiding this comment.
What: Ensure that the styles applied for font families and box-sizing are valid and impactful.
Why: While custom styles can be useful, utilizing Tailwind CSS along with predefined utility classes can ensure consistency and avoid specificity conflicts in the application.
How: Review the custom class names and ensure they follow the standards of Tailwind CSS. If these styles could be simplified or replaced with Tailwind utility classes (like 'font-sans' or 'box-border'), consider refactoring them.
| @@ -1,30 +1,30 @@ | |||
| import React from 'react'; | |||
There was a problem hiding this comment.
What: Avoid needless modifications when there are no changes in functionality.
Why: While you are updating or modifying the file, ensure that the changes are not purely for spacing or formatting. This can lead to misrepresentations of the actual changes in the codebase.
How: Consider reverting formatting changes if they do not significantly add value or functionality to the file. Focus on maintaining a clean commit history.
| import { injectAxe, checkA11y, configureAxe } from 'axe-playwright'; | ||
|
|
||
| export default { | ||
| async preVisit(page) { |
There was a problem hiding this comment.
What: The code does not validate if the parameters exist before accessing them, which could lead to runtime errors if any of these parameters are undefined.
Why: Accessing properties of undefined could cause your tests to fail unexpectedly, making debugging difficult. It's crucial to ensure that the parameters you're accessing are defined to maintain robustness in your test suite.
How: You can validate if 'parameters' and its child properties are defined before accessing them. For instance, instead of directly accessing 'params.rules', you could check: const rules = storyContext.parameters?.a11y?.config?.rules || {}; and proceed with using the 'rules' variable.
| // Get the entire context of a story, including parameters, args, argTypes, etc. | ||
| const storyContext = await getStoryContext(page, context); | ||
| // Apply story-level a11y rules | ||
| await configureAxe(page, { |
There was a problem hiding this comment.
What: Complex logic is nested within the async 'postVisit' function. This could make it harder to read and maintain in the future.
Why: It's generally a good practice to use early returns to keep code clean, especially in asynchronous functions, as it helps to reduce indentation levels and fosters readability.
How: You can refactor the 'postVisit' function to separate the checks into their own function or to return early for the disabled stories. For example:
if (storyContext.parameters?.a11y?.disable) {
return;
}
// Continue with the remaining logic...
| if (storyContext.parameters?.a11y?.disable) { | ||
| return; | ||
| } | ||
|
|
There was a problem hiding this comment.
What: The default value for the 'element' variable is currently hardcoded as '#storybook-root'. This may limit flexibility if stories vary in terms of structure or element targeting.
Why: Hardcoded values can create issues when the test setup fails to adjust for different scenarios or story structures. Having the ability to define different root elements can avoid accidental targeting of incorrect elements and help in customization.
How: Consider allowing developers or testers to set the default element in configuration or as an additional parameter. This could be achieved by adjusting how you derive the 'element' variable: const element = storyContext.parameters?.a11y?.element || defaultElement; where 'defaultElement' is a variable that can be adjusted or passed around.
| @@ -1,3 +1,3 @@ | |||
| // Project annotations (decorators, parameters) from preview.tsx are | |||
There was a problem hiding this comment.
What: Consider whether using instead of is necessary in your setting as it may affect compatibility across different operating systems that handle new lines in various ways.
Why: Using consistent newline characters across your files improves compatibility and reduces issues with version control systems that may handle line endings differently between contributors.
How: You can use either or consistently across your project. If you expect cross-platform contributions, consider configuring Git to use LF ( ) for all files to ensure consistent newline characters.
| // Project annotations (decorators, parameters) from preview.tsx are | ||
| // automatically applied by @storybook/addon-vitest since Storybook 10.3. | ||
| // Add any custom global test setup here if needed. | ||
| // Project annotations (decorators, parameters) from preview.tsx are |
There was a problem hiding this comment.
What: Make sure to review the need for global test setup comments. Comments can become outdated and if the setup is no longer relevant it can confuse maintainers.
Why: Redundant comments or comments that don't contribute valuable information clutter your code and make it harder for others to understand the purpose of the setup without additional context.
How: Regularly assess comments for relevance, and remove or update those that are no longer useful. Alternatively, consider providing a more contextual comment detailing specific configurations if necessary.
Bumps lodash and @microsoft/api-extractor. These dependencies needed to be updated together.
Updates
lodashfrom 4.17.23 to 4.18.1Release notes
Sourced from lodash's releases.
Commits
cb0b9b9release(patch): bump main to 4.18.1 (#6177)75535f5chore: prune stale advisory refs (#6170)62e91bcdocs: remove n_ Node.js < 6 REPL note from README (#6165)59be2derelease(minor): bump to 4.18.0 (#6161)af63457fix: broken tests for _.template 879aaa91073a76fix: linting issues879aaa9fix: validate imports keys in _.templatefe8d32efix: block prototype pollution in baseUnset via constructor/prototype traversal18ba0a3refactor(fromPairs): use baseAssignValue for consistent assignment (#6153)b819080ci: add dist sync validation workflow (#6137)Updates
@microsoft/api-extractorfrom 7.57.6 to 7.58.1Changelog
Sourced from
@microsoft/api-extractor's changelog.Commits
981ef14Bump versions [skip ci]ffa32f2Update changelogs [skip ci]7ab9bfdBump lodash 4.18.1 to address CVEs (#5744)d9a40b4Bump versions [skip ci]71a39c9Update changelogs [skip ci]de42395[api-extractor] Upgrade bundled TypeScript to 5.9 (#5727)8740839Bump versions [skip ci]6861350Update changelogs [skip ci]bcf89c8chore: bump decoupled local dependencies (#5692)ee40f81Bump versions [skip ci]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)You can disable automated security fix PRs for this repo from the Security Alerts page.