fix: bump intlify/utils v1 #14
Conversation
WalkthroughThe changes consolidate the Changes
Sequence Diagram(s)sequenceDiagram
participant App as Application
participant OldFlow as Old Locale Detection
participant NewFlow as New Locale Detection
participant Utils as `@intlify/utils`
rect rgb(240, 248, 255)
Note over OldFlow: Legacy: Raw event/context
App->>OldFlow: Pass event/ctx
OldFlow->>Utils: getHeaderLocale(event/ctx)
Utils-->>OldFlow: Extracted locale
OldFlow-->>App: Detected locale
end
rect rgb(240, 255, 240)
Note over NewFlow: Updated: WebRequest abstraction
App->>NewFlow: detectLocaleFromAcceptLanguageHeader
NewFlow->>NewFlow: Convert to WebRequest<br/>(h3: toWebRequest(event)<br/>hono: ctx.req.raw)
NewFlow->>Utils: getHeaderLocale(WebRequest)
Utils-->>NewFlow: Extracted locale
NewFlow-->>App: Detected locale
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
commit: |
![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
📜 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 (7)
packages/h3/package.json(1 hunks)packages/h3/src/index.test.ts(2 hunks)packages/h3/src/index.ts(2 hunks)packages/hono/package.json(1 hunks)packages/hono/src/index.test.ts(3 hunks)packages/hono/src/index.ts(2 hunks)pnpm-workspace.yaml(1 hunks)
🔇 Additional comments (8)
packages/hono/package.json (1)
66-66: LGTM!The migration to catalog-based dependency resolution aligns with the workspace configuration in
pnpm-workspace.yaml.packages/h3/package.json (1)
67-67: LGTM!The catalog-based dependency resolution ensures consistency with the workspace configuration.
packages/hono/src/index.test.ts (1)
17-21: LGTM!The test mocks correctly reflect the updated header access pattern using
req.raw.headers.get(), which aligns with the implementation changes inpackages/hono/src/index.ts.Also applies to: 61-65, 82-86
packages/hono/src/index.ts (2)
174-175: Verify the signature change forgetHeaderLocale.The function now passes
ctx.req.raw(the raw Request object) instead of the Hono Context. Ensure this matches the expected signature in@intlify/utilsv1 and that header retrieval works correctly across different Hono runtimes.
13-13: No issues found. The import path change is valid and compatible.The @intlify/utils/hono subpath remains available in the current package version, and
getHeaderLocaleis correctly available from the main@intlify/utilsexport. The code at lines 13 and 15 is compatible with the @intlify/utils package structure—there is no breaking change or import conflict.Likely an incorrect or invalid review comment.
packages/h3/src/index.ts (2)
175-176: LGTM!The use of
toWebRequest(event)provides a clean abstraction layer, converting the H3Event to a standard WebRequest interface for header extraction. This aligns well with the cross-framework compatibility goals.
19-20: No action required — the h3 subpath export is supported.@intlify/utils provides environment subpaths (including "h3") so you can import like import { ... } from "@intlify/utils/h3". The code correctly exports from
@intlify/utils/h3on line 22, and this subpath is properly supported by the package. The refactoring (importinggetHeaderLocalefrom the main@intlify/utilspackage and re-exporting the h3 subpath) is valid and intentional.Likely an incorrect or invalid review comment.
packages/h3/src/index.test.ts (1)
15-21: LGTM!The test mocks correctly simulate the H3 web interface by adding
web.request.headers.get(), which aligns with the use oftoWebRequest(event)in the implementation. The tests also maintain the existingnode.req.headersstructure for completeness.Also applies to: 67-73
| typescript: ^5.9.3 | ||
| tsdown: ^0.16.4 | ||
| publint: ^0.3.15 | ||
| '@intlify/utils': ^1.0.1 |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the new major version and check for breaking changes.
This is a major version upgrade for @intlify/utils (from 0.x to 1.x). Ensure that version ^1.0.1 exists and review the changelog for any breaking changes that might affect the workspace.
🌐 Web query:
What are the breaking changes in @intlify/utils version 1.0.1?
💡 Result:
I can look this up — may I search the web for the @intlify/utils v1.0.1 changelog/releases?
The specified version of @intlify/utils does not exist.
The latest version of @intlify/utils is 0.13.0, last published 2 years ago. Version ^1.0.1 does not exist in the npm registry. This will cause dependency resolution to fail unless this is a planned future release or the version specification is incorrect. Verify that the version constraint should be updated to match an existing release (e.g., ^0.13.0) or confirm this version will be published.
🤖 Prompt for AI Agents
In pnpm-workspace.yaml around line 11, the dependency entry '@intlify/utils':
^1.0.1 references a non-existent release and will break installs; update the
version constraint to a valid published version (for example '^0.13.0') or
change it to a tag that exists (e.g., 'latest') / a workspace path if you intend
to use a local package, then run pnpm install to verify resolution succeeds.
Description
Linked Issues
Additional context
Summary by CodeRabbit