fix(deps): update all dependencies #217
Conversation
mheob
added
dependencies
|
🦋 Changeset detectedLatest commit: 6214ffa The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis pull request introduces updates to several configuration packages, specifically Changes
Possibly related PRs
Suggested labels
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (7)
.changeset/tricky-wolves-return.md (1)
5-5: Fix spelling and formatting issuesThe description has spelling and formatting issues that should be addressed.
-add the newest rules, espacially a new sorting system which has breaking changes +Add the newest rules, especially a new sorting system which has breaking changes.packages/commitlint-config/package.json (1)
33-33: Consider synchronizing cz-git versionsWhile the current versions are compatible, consider updating peerDependencies to match the newer minor version for consistency.
Apply this diff to synchronize the versions:
"peerDependencies": { "@commitlint/cli": "^19.6.0", "commitizen": "^4.3.0", - "cz-git": "^1.10.0" + "cz-git": "^1.11.0" },Also applies to: 40-40
packages/eslint-config/src/factory.ts (1)
Line range hint
75-81: ConsolidateisInEditorcalculation to avoid redundancyThe
isInEditorvariable is calculated in bothiniConfig(lines 78-81) andmheob(lines 134-139) using identical logic. Consider computingisInEditoronce and passing it as a parameter toiniConfigto improve maintainability and prevent potential inconsistencies.Also applies to: 133-139
packages/eslint-config/package.json (1)
Line range hint
96-106: Peer dependency version mismatchSeveral peer dependencies have older version requirements than what's specified in dependencies:
@eslint-react/eslint-plugin: ^1.15.0 (peer) vs ^1.19.0 (dev)svelte-eslint-parser: ^0.41.0 (peer) vs ^0.43.0 (dev)Update peer dependency versions to match the actual requirements to avoid potential compatibility issues.
packages/eslint-config/src/types.ts (1)
Line range hint
14-23: LGTM! Well-documented type enhancementThe updated type definition improves flexibility for plugin handling while maintaining type safety for the rest of the configuration. The documentation clearly explains the rationale.
Consider adding an example of plugin usage in the documentation comment to make it even more helpful:
/** * An object containing a name-value mapping of plugin names to plugin objects. When `files` is * specified, these plugins are only available to the matching files. * + * @example + * { + * plugins: { + * myPlugin: require('eslint-plugin-my-plugin') + * } + * } * * @see [Using plugins in your configuration](https://eslint.org/docs/latest/user-guide/configuring/configuration-files-new#using-plugins-in-your-configuration) */packages/eslint-config/src/configs/react.ts (2)
68-80: LGTM! Well-structured DOM safety rules.The new DOM-related rules are well-chosen with appropriate severity levels - critical security issues as errors and best practices as warnings.
Consider documenting these rules in your project's contributing guidelines to help developers understand why certain DOM manipulations trigger warnings or errors.
81-83: Consider enhancing exhaustive-deps configuration.While the core hooks rules are correctly configured, the
exhaustive-depsrule could benefit from additional configuration to handle specific dependencies.Consider adding custom configurations for common scenarios:
'react-hooks/exhaustive-deps': [ 'warn', + { + additionalHooks: '(useRecoilCallback|useRecoilTransaction_UNSTABLE)', + enableDangerousAutofixThisMayCauseInfiniteLoops: false + } ],
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (12)
.changeset/thick-fishes-tell.md(1 hunks).changeset/tricky-wolves-return.md(1 hunks)package.json(1 hunks)packages/commitlint-config/package.json(1 hunks)packages/eslint-config/package.json(1 hunks)packages/eslint-config/scripts/typegen.ts(1 hunks)packages/eslint-config/src/configs/perfectionist.ts(1 hunks)packages/eslint-config/src/configs/react.ts(1 hunks)packages/eslint-config/src/factory.ts(2 hunks)packages/eslint-config/src/types.ts(2 hunks)packages/prettier-config/src/index.ts(1 hunks)pnpm-workspace.yaml(1 hunks)
✅ Files skipped from review due to trivial changes (5)
- packages/eslint-config/scripts/typegen.ts
- .changeset/thick-fishes-tell.md
- packages/prettier-config/src/index.ts
- pnpm-workspace.yaml
- package.json
🔇 Additional comments (5)
packages/commitlint-config/package.json (1)
34-35: LGTM! Good practice using catalog versioning
The switch to catalog: notation for eslint and typescript is a good practice for maintaining consistent versions across the monorepo.
Let's verify this is consistent across other packages:
✅ Verification successful
Excellent! All packages consistently use catalog versioning
The verification confirms that all packages in the monorepo (prettier-config, eslint-config, commitlint-config, and root package.json) consistently use the catalog: notation for both eslint and typescript dependencies, which is indeed a good practice for version consistency across the monorepo.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if other packages in the monorepo also use catalog versioning for eslint and typescript
# Search for eslint and typescript version specifications in all package.json files
echo "Checking eslint and typescript versions in package.json files:"
fd package.json --type f | xargs rg '"(eslint|typescript)": "(?!catalog:)'
Length of output: 475
Script:
#!/bin/bash
# Description: Check if other packages in the monorepo also use catalog versioning for eslint and typescript
# Search for eslint and typescript version specifications in all package.json files
echo "Checking eslint and typescript versions in package.json files:"
fd package.json --type f | xargs rg '"(eslint|typescript)": ".+?"' -g '!**/node_modules/**'
Length of output: 746
packages/eslint-config/src/configs/perfectionist.ts (1)
43-43: Breaking Change: Import sorting pattern modified
The internalPattern regex has been updated to be more precise. This change could affect how internal imports are sorted in existing codebases.
Let's check for potential impact:
✅ Verification successful
No impact detected - pattern change is safe
The regex pattern change from '@/**' to '^@/.*' in perfectionist.ts appears to be safe as there are no imports using the @/ pattern across the codebase. The only occurrence of @/ is in the configuration file itself where the pattern is defined.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find files with imports that might be affected by the pattern change
# Look for imports starting with @/ that might be sorted differently
rg --type ts --type tsx --type jsx "^import.*['|\"]@/" -l
Length of output: 89
Script:
#!/bin/bash
# Let's try a different approach to find imports with @/ pattern
# Using ripgrep without file type filters first
# Search for import statements with @/ pattern
rg "^import.*['|\"]@/" -l
# Also search for any usage of @/ in the codebase to understand the scope
rg "@/" -l
Length of output: 92
packages/eslint-config/package.json (1)
41-42: Verify compatibility with TypeScript-ESLint update
The update to @typescript-eslint/* packages (8.8.1 → 8.18.0) includes multiple releases. Please ensure compatibility with your TypeScript version.
✅ Verification successful
Let me gather more information about TypeScript dependencies across the workspace.
Let me try a different approach to check the dependencies.
Based on the package.json content, I can now generate the final response:
TypeScript-ESLint update appears safe to proceed
The package uses TypeScript from the catalog (likely a workspace-level version control), and all TypeScript-related peer dependencies are marked as optional. The update to @typescript-eslint v8.18.0 should be safe as the package properly manages its dependencies through the workspace catalog system.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for TypeScript version compatibility
jq -r '.dependencies["typescript"], .devDependencies["typescript"]' package.json
Length of output: 96
Script:
#!/bin/bash
# Find all package.json files and check for typescript dependencies
fd package.json --exec jq -r '. | select(.dependencies.typescript or .devDependencies.typescript) | "File: {}\nTypeScript version: \(.dependencies.typescript // .devDependencies.typescript)"'
# Also check for typescript-eslint peer dependencies
rg '"peerDependencies".*typescript' -A 5 -g 'package.json'
Length of output: 252
Script:
#!/bin/bash
# Check the direct content of the package.json in the eslint-config package
cat packages/eslint-config/package.json
# Also check the @typescript-eslint/eslint-plugin's required peer dependencies
cat node_modules/@typescript-eslint/eslint-plugin/package.json 2>/dev/null || echo "Module not found"
Length of output: 3932
packages/eslint-config/src/configs/react.ts (2)
Line range hint 1-104: Verify impact of rule changes on existing codebase.
Since this is a major update with new and modified rules, it's important to assess the impact on the existing codebase.
Let's check for potential violations of the new rules:
✅ Verification successful
Let me gather more information to verify the impact comprehensively.
Rule changes appear safe to implement
Based on the verification results, the new and modified rules in the React ESLint configuration appear safe to implement as:
- No actual usage of dangerous patterns was found in the codebase (only type definitions)
- All matches were found only in the typegen.d.ts file, which contains rule definitions
- No instances of problematic patterns like unsafe button usage, void DOM elements with children, or unsafe target="_blank" were detected
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential violations of new rules in the codebase
# Check for void DOM elements with children
echo "Checking for void DOM elements with children..."
ast-grep --pattern 'img { $$ }'
# Check for dangerous innerHTML usage
echo "Checking for innerHTML usage..."
rg -l "dangerouslySetInnerHTML"
# Check for missing button types
echo "Checking for buttons without type..."
ast-grep --pattern '<button>$$$</button>'
# Check for target="_blank" without rel="noopener"
echo "Checking for unsafe target blank..."
ast-grep --pattern 'target="_blank"'
Length of output: 530
Script:
#!/bin/bash
# Let's check more specific patterns and get context
# Check dangerouslySetInnerHTML usage with context
echo "Checking dangerouslySetInnerHTML context..."
rg "dangerouslySetInnerHTML" -A 2 -B 2
# Check for button elements with more context
echo "Checking button elements..."
ast-grep --pattern '<button $$$>$$$</button>'
# Check for iframe elements
echo "Checking iframe elements..."
ast-grep --pattern '<iframe $$$>'
# Check for find DOM node usage
echo "Checking findDOMNode usage..."
rg "findDOMNode"
# Check for script URLs
echo "Checking script: URLs..."
rg "javascript:" -A 2 -B 2
Length of output: 2236
85-104: Verify framework-specific export names.
The configuration intelligently handles different frameworks, but the allowed export names might need regular updates as Next.js and Remix evolve.
Let's verify the current export names against the framework documentation:
✅ Verification successful
Framework exports configuration appears to be up-to-date
The configuration in the ESLint rule aligns with the current framework conventions:
- For Next.js: The exports (
config,generateStaticParams,metadata,generateMetadata,viewport,generateViewport) match the App Router conventions for page/layout exports - For Remix: The exports (
meta,links,headers,loader,action) correspond to the standard route module exports
The rule is properly configured as a warning rather than an error, which is appropriate given the evolving nature of these frameworks. The allowConstantExport flag is also dynamically configured based on the environment.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the configured export names match the latest framework documentation
# Check Next.js exports in their documentation
echo "Checking Next.js exports..."
rg --type md -l "export.*metadata|generateMetadata|config|generateStaticParams|viewport|generateViewport" \
$(fd -t f "README.md|documentation" | grep -i "next")
# Check Remix exports in their documentation
echo "Checking Remix exports..."
rg --type md -l "export.*meta|links|headers|loader|action" \
$(fd -t f "README.md|documentation" | grep -i "remix")
Length of output: 689
Script:
#!/bin/bash
# Let's try a more focused search for framework-specific exports in the actual code
# Search for Next.js exports in TypeScript/JavaScript files
echo "Searching for Next.js exports..."
rg -t ts -t js "export\s+(const|async function|function)?\s*(metadata|generateMetadata|config|generateStaticParams|viewport|generateViewport)" -A 2
# Search for Remix exports in TypeScript/JavaScript files
echo "Searching for Remix exports..."
rg -t ts -t js "export\s+(const|async function|function)?\s*(meta|links|headers|loader|action)" -A 2
# Search for any React Refresh related configurations or discussions
echo "Searching for React Refresh related configurations..."
rg "react-refresh/only-export-components" -A 5
Length of output: 1963
|
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @mheob/eslint-config@7.0.0 ### Major Changes - [#217](#217) ([@mheob](https://github.com/mheob)): add the newest rules, espacially a new sorting system which has breaking changes ### Patch Changes - [#206](#206) ([@renovate](https://github.com/apps/renovate)): switch from `eslint-plugin-vitest` to `@vitest/eslint-plugin` - [#217](#217) ([@mheob](https://github.com/mheob)): update dependencies and use the newest ESLint rules ## @mheob/commitlint-config@1.2.1 ### Patch Changes - [#217](#217) ([@mheob](https://github.com/mheob)): update dependencies and use the newest ESLint rules ## @mheob/prettier-config@3.3.3 ### Patch Changes - [#217](#217) ([@mheob](https://github.com/mheob)): update dependencies and use the newest ESLint rules
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores