fix(deps): update all dependencies #93
Conversation
|
🦋 Changeset detectedLatest commit: ba0ef9e The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
WalkthroughThis update refactors configuration and tooling files, updates Node.js and dependency versions, and transitions build, lint, and formatting systems to new tools and standards. It removes legacy configuration files, introduces new ones for ESLint and Prettier, and restructures test suites with more granular coverage. Several scripts are simplified, and code style is modernized. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant HuskyHook
participant LintStaged
participant Commitlint
participant UseCorrectPM
User->>HuskyHook: Trigger commit-msg/pre-commit/pre-push/post-merge
alt If CI environment
HuskyHook-->>User: Exit (skip hook)
else
alt pre-commit
HuskyHook->>LintStaged: Run lint-staged
else pre-push
HuskyHook->>UseCorrectPM: Run use-correct-pm
else commit-msg
HuskyHook->>Commitlint: Run commitlint
else post-merge
HuskyHook->>HuskyHook: Check for pnpm-lock.yaml changes
alt If changed
HuskyHook->>HuskyHook: Run pnpm install
end
end
end
sequenceDiagram
participant ChangelogFn
participant GitHubAPI
participant User
User->>ChangelogFn: Call getReleaseLine or getDependencyReleaseLine
ChangelogFn->>GitHubAPI: Fetch PR/commit info (getInfo/getInfoFromPullRequest)
GitHubAPI-->>ChangelogFn: Return PR/commit/user data
ChangelogFn->>User: Return formatted changelog line with links
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
eslint.config.mjsOops! Something went wrong! :( ESLint: 9.27.0 Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@mheob/prettier-config' imported from /prettier.config.mjs commitlint.config.jsOops! Something went wrong! :( ESLint: 9.27.0 Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@mheob/prettier-config' imported from /prettier.config.mjs prettier.config.mjsOops! Something went wrong! :( ESLint: 9.27.0 Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@mheob/prettier-config' imported from /prettier.config.mjs
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #93 +/- ##
===========================================
+ Coverage 93.05% 100.00% +6.94%
===========================================
Files 5 3 -2
Lines 72 130 +58
Branches 19 33 +14
===========================================
+ Hits 67 130 +63
+ Misses 4 0 -4
+ Partials 1 0 -1
🚀 New features to boost your workflow:
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
.husky/commit-msg (1)
1-4: 💡 Verification agent🧩 Analysis chain
Verify that the simplified Husky hook still functions correctly.
The hook has been significantly simplified by removing the shebang and Husky environment sourcing. While the CI optimization is good, please ensure that:
- The hook still executes properly in local development environments
- Commitlint functionality works as expected without the Husky environment
- The script runs correctly without an explicit shebang
🏁 Script executed:
#!/bin/bash # Description: Test if the simplified Husky hook works correctly # Check if commitlint is available echo "Checking commitlint availability:" pnpm exec commitlint --version # Check if the hook file is executable echo -e "\nChecking hook file permissions:" ls -la .husky/commit-msg # Test hook execution (dry run) echo -e "\nTesting hook execution with a sample commit message:" echo "feat: test commit message" > test-commit-msg.tmp bash .husky/commit-msg test-commit-msg.tmp rm -f test-commit-msg.tmpLength of output: 621
Fix commitlint invocation in
.husky/commit-msgOur dry‐run shows that
pnpm exec commitlintis not found, so the hook will fail locally:
pnpm exec commitlint --versionreturned “Command ‘commitlint’ not found”- Without sourcing Husky’s environment, local binaries under
node_modules/.binaren’t on PATHPlease update the hook to ensure commitlint is installed and accessible. For example:
- Add a shebang and source Husky’s env so
pnpm execsees local bins- Verify
@commitlint/cliis indevDependencies- Or switch to
pnpm dlx commitlint --edit "$1"if you prefer not to source HuskyExample patch:
+ #!/usr/bin/env sh + . "$(dirname "$0")/_/husky.sh" [ -n "$CI" ] && exit 0 pnpm exec commitlint --edit "$1"
🧹 Nitpick comments (3)
README.md (1)
37-39: Replace hard tab indentation with spaces in JSON snippet
The code block uses a hard tab on line 38, triggering MD010 (no-hard-tabs). Switching to spaces will improve consistency and satisfy Markdown linting:- "changelog": ["@mheob/changeset-changelog", { "repo": "YOUR_ORG_OR_USER/YOUR_REPO" }], + "changelog": ["@mheob/changeset-changelog", { "repo": "YOUR_ORG_OR_USER/YOUR_REPO" }],🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
38-38: Hard tabs
Column: 1(MD010, no-hard-tabs)
prettier.config.mjs (1)
1-6: LGTM! Consider simplifying the configuration.The ES module format and JSDoc typing are well implemented. However, since no modifications are made to the imported config, the shallow copy is unnecessary.
Consider this simplified version:
import defaultConfig from '@mheob/prettier-config'; -/** @type {import('prettier').Config} */ -const config = { ...defaultConfig }; - -export default config; +/** @type {import('prettier').Config} */ +export default defaultConfig;src/get-release-line.test.ts (1)
43-44: Consider improving type safety in mocks.While
anytypes work for testing, you could improve type safety by creating proper mock return types or usingvi.mocked()for better TypeScript support.Example improvement:
- (getInfoFromPullRequest as any).mockResolvedValue({ + vi.mocked(getInfoFromPullRequest).mockResolvedValue({Also applies to: 52-53, 67-68, 115-120, 134-136
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (29)
.changeset/major-pets-sink.md(1 hunks).eslintrc.cjs(0 hunks).github/codecov.yml(1 hunks).github/dependabot.yml(1 hunks).github/stale.yml(1 hunks).github/workflows/check.yml(1 hunks).github/workflows/release.yml(2 hunks).husky/commit-msg(1 hunks).husky/post-merge(0 hunks).husky/pre-commit(0 hunks).husky/pre-push(0 hunks).nvmrc(1 hunks).prettierignore(0 hunks).prettierrc.cjs(0 hunks).vscode/settings.json(1 hunks)README.md(1 hunks)commitlint.config.js(1 hunks)eslint.config.mjs(1 hunks)package.json(2 hunks)prettier.config.mjs(1 hunks)scripts/prepare.ts(1 hunks)src/get-dependency-release-line.test.ts(1 hunks)src/get-dependency-release-line.ts(2 hunks)src/get-release-line.test.ts(1 hunks)src/get-release-line.ts(7 hunks)src/index.test.ts(0 hunks)src/index.ts(1 hunks)src/utils.test.ts(1 hunks)vitest.config.ts(1 hunks)
💤 Files with no reviewable changes (7)
- .prettierrc.cjs
- src/index.test.ts
- .prettierignore
- .husky/pre-push
- .husky/pre-commit
- .eslintrc.cjs
- .husky/post-merge
🧰 Additional context used
🧬 Code Graph Analysis (3)
src/get-dependency-release-line.test.ts (1)
src/get-dependency-release-line.ts (2)
getDependencyReleaseLinks(6-20)getDependencyReleaseLine(22-37)
src/utils.test.ts (1)
src/utils.ts (1)
errorMessage(1-2)
src/get-dependency-release-line.ts (1)
src/utils.ts (1)
errorMessage(1-2)
🪛 markdownlint-cli2 (0.17.2)
README.md
38-38: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (38)
.nvmrc (1)
1-1: Align Node.js version to project requirements
The.nvmrcfile version has been updated to 22 to match theenginesfield inpackage.jsonand CI workflows..github/stale.yml (1)
7-8: Remove unnecessary quotation marks from labels
TheexemptLabelsentries no longer need quotes aroundnot staleandsecurity, improving YAML readability while preserving functionality..github/codecov.yml (1)
7-7: Use unquoted numeric range for coverage thresholds
Therangefield is now specified as a bare numeric range (80...100), aligning with YAML best practices and simplifying parsing logic..github/dependabot.yml (2)
3-4: Unquote simple string values
Thepackage-ecosystemanddirectoryfields are now unquoted, which is valid YAML and increases consistency with other config entries.
6-8: Optimize quoting for schedule fields
Theintervalanddayfields are correctly unquoted, and thetimefield retains quotes because it contains a colon, which requires quoting in YAML.commitlint.config.js (1)
1-4: LGTM! Clean migration to ES modules.The conversion from CommonJS to ES module syntax is correctly implemented. The import and export statements follow proper ES module conventions while preserving the existing configuration logic.
vitest.config.ts (1)
6-10: LGTM! Improved coverage configuration.The changes enhance the test coverage setup:
- Switching to 'v8' provider typically offers better performance and accuracy
- The include/exclude patterns are well-targeted: covering all TypeScript source files while excluding index files (often just re-exports)
eslint.config.mjs (1)
1-3: LGTM! Modern ESLint configuration.The new flat config format is correctly implemented using ES modules. The import and export are properly structured, and calling
defaultConfig({})with an empty options object is the correct way to use the imported configuration function.src/utils.test.ts (1)
1-17: LGTM! Well-structured test suite.The test cases comprehensively validate the
errorMessageexport:
- Tests for correct instruction content
- Validates the example format is present
- Confirms the message starts correctly
All assertions align with the actual error message content from
src/utils.tsand should pass successfully..changeset/major-pets-sink.md (1)
1-6: LGTM! Changeset properly documents the dependency update.The changeset file correctly follows the standard format and appropriately categorizes this as a patch-level update for dependency changes.
.github/workflows/check.yml (1)
21-22: Good cleanup! Unnecessary quotes removed from YAML values.The removal of quotes from
node-version-fileandcacheparameters is a valid simplification that improves readability without affecting functionality..github/workflows/release.yml (2)
8-8: LGTM! Valid YAML syntax simplification.Removing unnecessary quotes around the package.json path is a valid YAML syntax improvement.
30-31: LGTM! Consistent YAML formatting.The unquoted values for
node-version-fileandcacheare valid and consistent with modern YAML style.scripts/prepare.ts (4)
1-1: LGTM! Modern Node.js import style.Using the explicit
'node:process'import is the recommended modern approach for Node.js built-in modules.
5-5: LGTM! Cleaner environment variable access.The dot notation
process.env.CIis more readable than bracket notation.
8-8: Behavior change: now logging the return value.This changes the behavior from just calling
installHusky()to logging its return value. Ensure this is intentional.If the goal is just to call the function without output, revert to:
- console.log(installHusky()); + installHusky();
3-3:✅ Verification successful
Verify the husky import syntax.
The change from named import
{ install }to default importinstallHuskyneeds verification to ensure husky exports a default function.
🏁 Script executed:
#!/bin/bash # Check husky package exports to verify import syntax npm view husky main npm view husky exportsLength of output: 57
🏁 Script executed:
#!/bin/bash # Fetch the top of the published husky package’s index.js to inspect its exports version=$(npm view husky version) curl -fsSL "https://unpkg.com/husky@${version}/index.js" | head -n 50Length of output: 1326
Default import is correct for Husky
Husky’s publishedindex.jsusesexport default (…), soimport installHusky from 'husky'matches its default export and is the proper syntax. No further changes needed..vscode/settings.json (4)
2-2: LGTM! Consistent formatting improvement.The trailing comma addition improves consistency with the rest of the JSON structure.
4-12: LGTM! Proper ESLint delegation setup.Disabling Prettier and format-on-save while enabling ESLint auto-fix is the correct approach for delegating formatting responsibility to ESLint. The
organizeImports: "never"prevents conflicts with ESLint's import organization rules.
14-26: LGTM! Smart stylistic rule management.Silencing stylistic rules in the IDE while keeping them fixable is an excellent approach. This reduces visual noise while maintaining code quality through auto-fixing.
28-52: LGTM! Comprehensive language support.The extensive ESLint validation support covers all major web development file types, ensuring consistent linting across the entire project ecosystem.
src/get-dependency-release-line.test.ts (1)
1-94: Excellent comprehensive test coverage!This test file provides thorough coverage for both
getDependencyReleaseLinksandgetDependencyReleaseLinefunctions with well-structured test cases that cover:
- Normal operation with commit links
- Edge cases (missing commits, missing repo)
- Error conditions and empty responses
- Proper mocking of external dependencies
The test structure follows good practices with proper setup, isolation, and meaningful assertions.
package.json (3)
31-35: Build and development tooling updated appropriately.The migration from
tsuptotsdownandts-nodetotsxlooks well-configured. The simplified lint script and updated prepare script align with modern tooling practices.
76-78:✅ Verification successful
Verify Node.js version compatibility.
The engines field specifies
node: ">=22", which is quite recent. Ensure this aligns with your project's compatibility requirements and deployment environments.
🌐 Web query:
What is the current LTS version of Node.js and when was Node.js 22 released?💡 Result:
Current LTS Version of Node.js
The current Long Term Support (LTS) version of Node.js is Node.js 22 (codename: Jod)[1][2][5]. Node.js 22 entered Active LTS status on October 29, 2024, which means it is the recommended version for production environments and will continue receiving security and critical bug fixes for a guaranteed support period[5][3][10].
Node.js 22 Release Date
Node.js 22 was originally released on April 24, 2024, as the new "Current" release line[6][7][9]. It remained in the "Current" phase for six months before transitioning to Active LTS in October 2024[9][6][5].
Summary Table
Node.js Version LTS Status Initial Release LTS Start Notes 22.x (Jod) Active LTS 2024-04-24 2024-10-29 Current LTS as of May 2025[1][5][9] Key Points:
- Current LTS: Node.js 22.x (Jod)
- Node.js 22 Release Date: April 24, 2024[6][9]
- Transition to LTS: October 29, 2024[5][10]
Node.js 22 will remain in Active LTS until October 2025 and in Maintenance LTS until April 2027[3][5].
Citations:
- 1: https://nodejs.org/en/about/previous-releases
- 2: https://endoflife.date/nodejs
- 3: https://www.herodevs.com/blog-posts/node-js-end-of-life-dates-you-should-be-aware-of
- 4: https://nodejs.org/en/blog/vulnerability/may-2025-security-releases
- 5: http://nodesource.com/blog/Node.js-v22-Long-Term-Support-LTS/
- 6: https://openjsf.org/blog/nodejs-22-available
- 7: https://www.zealousys.com/blog/node-js-22/
- 8: https://blog.logrocket.com/node-js-24-new/
- 9: https://nodejs.org/en/blog/announcements/v22-release-announce
- 10: https://devcenter.heroku.com/changelog-items/3047
Engine Requirement Confirmed
Node.js 22 (codename “Jod”) is the current Active LTS (initial release April 24, 2024; LTS start October 29, 2024; supported until October 2025). The
>=22engine constraint in package.json aligns with the official LTS recommendation. Ensure all deployment targets are running Node 22+ before rolling out this change.
69-70:✅ Verification successful
Verify new build tools are stable.
The addition of
tsdownandtsxas build and development tools appears to be part of the modernization effort. These are relatively newer tools compared to the previoustsupandts-node.
🌐 Web query:
What are the latest stable versions of tsdown and tsx, and are there any known issues or security advisories for these packages?💡 Result:
As of May 28, 2025, the latest stable version of the
tsxpackage is 4.19.1. This version was published approximately three weeks ago. (npmjs.com)Regarding known issues, there have been reports of
tsxfailing in certain environments. For instance, users have encountered failures when runningtsxin Linux Docker CI environments, particularly with version 3.14.0. Additionally, there have been issues with directory imports since version 4.15.8. (github.com, github.com)In terms of security advisories, no direct vulnerabilities have been identified in the
tsxpackage itself. Snyk's vulnerability database reports no direct vulnerabilities for this package. (security.snyk.io)It's important to note that while
tsxitself has no known vulnerabilities, users should ensure that all dependencies and the Node.js environment are up to date to maintain overall security.Citations:
- 1: https://www.npmjs.com/package/tsx?activeTab=versions&utm_source=openai
- 2: Something is wrong with 3.14.0 (fails in a Linux Docker CI environment) privatenumber/tsx#363
- 3: directory import fails again since 4.15.8 privatenumber/tsx#607
- 4: https://security.snyk.io/package/npm/tsx?utm_source=openai
🌐 Web query:
What is the latest version of the npm package tsdown, and are there any known issues or security advisories reported for this package?💡 Result:
The latest version of the npm package
tsdownis 0.3.1, published approximately 7 hours ago. (jsr.io)
tsdownis an experimental bundler powered by Rolldown, currently under active development and not yet ready for production use. (github.com)As of now, there are no known security advisories or issues reported for the
tsdownpackage. However, it's important to note thattsdownis still in development and may not be suitable for production environments.For the most current information on security advisories, you can refer to the npm advisories database. (node.advisories.io)
Citations:
- 1: https://jsr.io/%40sxzz/tsdown?utm_source=openai
- 2: https://github.com/sxzz/tsdown?utm_source=openai
- 3: https://node.advisories.io/?utm_source=openai
🏁 Script executed:
#!/usr/bin/env bash echo "Checking tsdown on npm registry:" curl -s https://registry.npmjs.org/tsdown | jq '{ latest: .["dist-tags"].latest, version_0_12_4_exists: (.versions | has("0.12.4")) }' echo echo "Checking tsx on npm registry:" curl -s https://registry.npmjs.org/tsx | jq '{ latest: .["dist-tags"].latest, version_4_19_4_exists: (.versions | has("4.19.4")) }'Length of output: 546
Confirm build tool versions and evaluate maturity
- tsdown@^0.12.4 matches the npm “latest” dist-tag (0.12.4). It’s still an experimental bundler (Rolldown-powered) under active development—verify it meets your production readiness requirements.
- tsx@^4.19.4 matches the npm “latest” dist-tag (4.19.4). No direct security advisories have been reported, but there are known environment-specific issues (Linux Docker CI failures in earlier releases, directory-import bugs since 4.15.8). Ensure your CI workflows and import paths are fully tested.
src/get-dependency-release-line.ts (2)
6-9: Good practice: Exporting function with explicit return type.Making
getDependencyReleaseLinksexportable enables unit testing while the explicitPromise<string>return type improves type safety and documentation.
27-33: Code style improvements enhance readability.The changes to use dot notation for optional chaining (
options?.repo) and simplified arrow function syntax are good modernization improvements that maintain functionality while improving readability.src/get-release-line.ts (4)
7-46: Excellent type safety and testability improvements.Converting
GithubLinksto an exported interface and adding explicit return types togetReplacedChangelogenhances both type safety and enables comprehensive unit testing. The interface approach also allows for better extensibility compared to the previous type alias.
48-53: Good practice: Explicit return type for async function.Adding the explicit
Promise<GithubLinks>return type togetGitHubLinksimproves type documentation and catches potential return type mismatches at compile time.
91-109: Consistent export pattern with utility functions.Exporting
getUserLinkandlinkifyIssuewith explicit return types follows the established pattern and enables thorough unit testing of these utility functions. The code style improvements (removing unnecessary parentheses in arrow functions) enhance readability.
61-61: Test coverage directive updated appropriately.The change from
istanbul ignore nexttov8 ignore nextaligns with modern test coverage tools. This is likely related to the migration to Vitest which uses V8's built-in code coverage.src/get-release-line.test.ts (7)
1-1: ESLint disable is acceptable for test files.The
ts/no-explicit-anydisable is reasonable here since test files often requireanytypes for mocking external dependencies.
14-17: Well-structured module mocking.The vi.mock setup properly mocks the external GitHub API functions, enabling controlled testing without actual API calls.
19-35: Comprehensive test for metadata extraction.The test properly validates the extraction of commit hash, PR number, and users from changeset summaries, as well as confirming the metadata lines are removed from the final changelog.
37-75: Thorough coverage of GitHub link scenarios.The test suite covers all the main code paths:
- PR-based link fetching
- Commit-based link fetching
- Fallback when no data is available
- Commit link formatting when commitFromSummary is present
77-89: Good edge case coverage for user links.Tests cover the main scenarios: users from summary, fallback user link, and empty cases. The expected output format matches typical GitHub user link patterns.
91-98: Basic but adequate linkification test.The test validates the core functionality of converting issue references to GitHub issue links.
100-147: Excellent integration test coverage.The tests cover:
- Error handling when required repo option is missing
- Full release line formatting with PR and user links
- Fallback to commit links when PR is unavailable
The test expectations properly validate the final formatted output.
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/[email protected] ### Patch Changes - [#93](#93) ([@mheob](https://github.com/mheob)): update all dependencies - [#53](#53) ([@renovate](https://github.com/apps/renovate)): chore(deps): update all non-major dependencies ## Summary by CodeRabbit - **Chores** - Updated the changelog with a new entry for version 3.0.2, documenting recent dependency updates. - Incremented the package version to 3.0.2. - Removed an obsolete changeset file related to dependency updates. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Summary by CodeRabbit
New Features
Bug Fixes
Chores
Refactor
Tests
Documentation