docs: use string status names consistently across remaining files #744
Conversation
|
Warning Rate limit exceeded@braden-w has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 3 minutes and 21 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (5)
WalkthroughDocumentation examples across multiple guides were updated to demonstrate string-based HTTP status usage instead of numeric codes. Additionally, clarifications on status string syntax were added to status/headers and error-handling documentation. No functional code changes or API modifications. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
docs/essential/best-practice.md (1)
368-371: Commented-out isSignIn examples may have inverted conditionEven though this section is commented out, both
isSignInexamples currently return Unauthorized whensession.valueis truthy rather than when it’s missing. If these snippets are ever re-enabled, you’ll probably wantif (!session.value) return status("Unauthorized")for consistency with the other auth examples.Also applies to: 390-394
docs/tutorial/patterns/error-handling/index.md (1)
48-48: Markdownlint MD010 (hard tabs) hint on this linemarkdownlint-cli2 is flagging a hard tab at the start of this line (MD010). If your docs style is moving away from tabs, consider converting this fenced code block’s indentation to spaces or updating the markdownlint config to ignore code fences.
docs/tutorial/getting-started/encapsulation/index.md (1)
45-48: markdownlint MD010 (hard tabs) warnings are non-blocking but worth notingmarkdownlint-cli2 flags hard tabs on nearby lines in this fenced code. If you want a clean lint run, consider converting the leading tabs in this block to spaces or relaxing MD010 for code fences; otherwise this can likely be deferred since it doesn’t affect rendered docs.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (18)
docs/eden/treaty/response.md(2 hunks)docs/essential/best-practice.md(3 hunks)docs/essential/life-cycle.md(2 hunks)docs/essential/plugin.md(1 hunks)docs/index.md(3 hunks)docs/integrations/better-auth.md(1 hunks)docs/key-concept.md(1 hunks)docs/patterns/error-handling.md(1 hunks)docs/patterns/extends-context.md(1 hunks)docs/tutorial/getting-started/encapsulation/data.ts(2 hunks)docs/tutorial/getting-started/encapsulation/index.md(6 hunks)docs/tutorial/getting-started/guard/index.md(4 hunks)docs/tutorial/getting-started/life-cycle/index.md(2 hunks)docs/tutorial/getting-started/status-and-headers/index.md(1 hunks)docs/tutorial/getting-started/validation/index.md(1 hunks)docs/tutorial/patterns/error-handling/index.md(1 hunks)docs/tutorial/patterns/extends-context/index.md(1 hunks)docs/tutorial/patterns/macro/index.md(2 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
docs/index.md
115-115: Hard tabs
Column: 1
(MD010, no-hard-tabs)
162-162: Hard tabs
Column: 1
(MD010, no-hard-tabs)
192-192: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/essential/plugin.md
118-118: Hard tabs
Column: 1
(MD010, no-hard-tabs)
121-121: Hard tabs
Column: 1
(MD010, no-hard-tabs)
122-122: Hard tabs
Column: 1
(MD010, no-hard-tabs)
125-125: Hard tabs
Column: 1
(MD010, no-hard-tabs)
126-126: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/eden/treaty/response.md
149-149: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/tutorial/getting-started/guard/index.md
142-142: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/tutorial/getting-started/life-cycle/index.md
152-152: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/tutorial/patterns/error-handling/index.md
48-48: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/tutorial/getting-started/status-and-headers/index.md
52-52: Hard tabs
Column: 1
(MD010, no-hard-tabs)
53-53: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/tutorial/getting-started/encapsulation/index.md
47-47: Hard tabs
Column: 1
(MD010, no-hard-tabs)
48-48: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (20)
docs/tutorial/patterns/extends-context/index.md (1)
163-167: Resolve example now uses string status name consistentlyThe change to
status("Unauthorized")here keeps the same control flow while matching the new string-based status style used elsewhere in the docs. Looks good.docs/essential/best-practice.md (1)
315-323: AuthService macro: string-based Unauthorized status is consistentUsing
status("Unauthorized")here preserves the existing behavior (reject when no session cookie) and aligns with the project-wide move away from numeric401in docs.docs/integrations/better-auth.md (1)
187-196: Better Auth macro resolve uses string Unauthorized status correctlySwitching the missing-session check to
status("Unauthorized")keeps the same early-return behavior while matching the new documentation convention.docs/patterns/extends-context.md (1)
317-324: Derive auth example now matches string status conventionUsing
status("Unauthorized")on missingauthorizationpreserves the early-exit error behavior and keeps this example consistent with other auth-related docs.docs/tutorial/patterns/macro/index.md (2)
62-69: Auth macro example: Unauthorized string status is appropriateThe macro’s
beforeHandlenow returnsstatus("Unauthorized")whensession.valueis missing, which matches the rest of the auth docs without changing behavior.
111-117: Fibonacci macro: explicit “I’m a teapot” reason phrase looks goodUsing
status("I'm a teapot")here keeps the 418-style example while making the reason phrase explicit and consistent with the string-based status style elsewhere.docs/tutorial/patterns/error-handling/index.md (1)
44-49: Quoting change in onError handler is safeSwitching to a double-quoted string here preserves the exact message while simplifying escaping; the 418 example remains intact.
docs/tutorial/getting-started/encapsulation/data.ts (1)
7-10: Encapsulation playground code: Unauthorized/Forbidden strings align with testsBoth guards now use
status("Unauthorized")andstatus("Forbidden")instead of numeric codes, while the testcases below still assert on 401 and 403. This matches the new documentation convention without changing the observable behavior of the examples.Also applies to: 18-21
docs/tutorial/getting-started/encapsulation/index.md (1)
31-37: Encapsulation examples consistently migrated to string status namesAll the updated snippets here now use
status("Unauthorized")for missingnameandstatus("Forbidden")for underageage, which keeps the same auth/validation behavior while aligning with the project-wide string status convention. The examples remain consistent with the corresponding playground tests and other docs.Also applies to: 45-51, 71-76, 145-147, 171-188
docs/key-concept.md (1)
22-23: Consistent status name usage in lifecycle examples.Elysia supports setting status codes using the common name of the status code instead of using a number. The conversion from
status(401)tostatus("Unauthorized")is consistent with this feature and aligns with the PR objectives.Also applies to: 31-32, 37-37
docs/eden/treaty/response.md (1)
33-33: Consistent string status usage in Eden examples.The conversion from numeric to string status codes is consistent throughout. However, line 149 contains a hard tab character that violates Markdown formatting standards.
Apply this diff to fix the hard tab on line 149:
- if(name === 'Otto') return status("Bad Request") + if(name === 'Otto') return status("Bad Request")(The difference is subtle—replace the leading hard tab with spaces to match the file's indent pattern.)
Also applies to: 149-149
docs/tutorial/getting-started/guard/index.md (1)
40-40: Consistent string status usage in guard examples.The conversion to string-based status names is applied consistently across all guard examples. However, line 142 contains a hard tab that should be replaced with spaces.
Apply this diff to fix the hard tab on line 142:
- if(!name) return status("Unauthorized") + if(!name) return status("Unauthorized")Also applies to: 51-51, 91-91, 142-142
docs/tutorial/getting-started/validation/index.md (1)
137-137: Status(418) conversion aligns with PR approach.The conversion to string form
status("I'm a teapot", 'Hello Elysia!')is consistent with other examples in the PR. While the PR objectives note that 418 examples were "kept with explanatory notes," the documentation indocs/tutorial/getting-started/status-and-headers/index.md(lines 56-61) confirms both numeric and string forms are equivalent and interchangeable.docs/index.md (2)
115-115: Hard tabs detected in status examples.All three instances contain hard tabs that violate Markdown formatting standards and should be replaced with spaces to match the file's indentation.
Apply this diff to fix hard tabs:
- if(headers.authorization !== type) - return status("Unauthorized") + if(headers.authorization !== type) + return status("Unauthorized")(Repeat for lines 162 and 192.)
Also applies to: 162-162, 192-192
217-217: Inconsistent status code conversion.Lines 217 and 423 still use
status(400, "Oh no")with a numeric code, while most other files have been converted to string equivalents (status("Bad Request", ...)). Per the PR objectives, only status(418) and status(404) are noted as exceptions. Please clarify whether status(400) should also be converted or if these are intentional exceptions.Also applies to: 423-423
docs/patterns/error-handling.md (1)
311-311: Clear documentation of string status support.The added explanatory text effectively documents that both numeric and string forms are supported for HTTP status codes. This provides helpful guidance for users choosing between approaches.
docs/essential/life-cycle.md (1)
505-505: Consistent string status usage in lifecycle examples.The conversion from numeric to string status codes demonstrates the API capability and improves code clarity in auth validation contexts.
Also applies to: 530-530
docs/tutorial/getting-started/status-and-headers/index.md (2)
52-52: Typo fix in status code example.The correction from
"I'm a teapot'"to"I'm a teapot"fixes an unclosed string literal and makes the example valid. However, lines 52-53 contain hard tabs.Apply this diff to fix hard tabs:
- .get('/', ({ status }) => status(418, "I'm a teapot")) + .get('/', ({ status }) => status(418, "I'm a teapot"))
56-65: Excellent documentation of status code flexibility.The addition clearly explains that both numeric and string forms are equivalent and supported, with a helpful note that string names provide TypeScript autocompletion. This enhances the learning experience for developers.
docs/tutorial/getting-started/life-cycle/index.md (1)
65-65: Clear explanation of string status syntax.The documentation addition explaining
status("I'm a teapot")alongside the numeric example and doc link is helpful context for users.
docs/essential/plugin.md
Outdated
| .onBeforeHandle(({ status }) => status("Unauthorized")) | ||
| .get('/profile', ({ status }) => status("Unauthorized")) |
There was a problem hiding this comment.
Approve status code conversions; fix hard tab indentation.
The conversions from status(401) to status("Unauthorized") are correct and align with the PR objective. However, the code examples use hard tabs for indentation, which violates the markdown MD010 linting rule. Replace all leading tabs with spaces (typically 2–4 spaces per indent level) for consistency.
Example fix for lines 118–119:
- .onBeforeHandle(({ status }) => status("Unauthorized"))
- .get('/profile', ({ status }) => status("Unauthorized"))
+ .onBeforeHandle(({ status }) => status("Unauthorized"))
+ .get('/profile', ({ status }) => status("Unauthorized"))Apply the same indentation fix (tabs → spaces) to lines 127–128 and line 133.
Also applies to: 127-128, 133-133
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
118-118: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In docs/essential/plugin.md around lines 118-119 (and also apply to 127-128 and
133), the example code uses hard tab characters for indentation which violates
MD010; replace all leading tabs with spaces (use 2–4 spaces per indent level
consistent with the file) so the lines read with space-based indentation while
leaving the status("Unauthorized") edits intact.
| new Elysia() | ||
| .onBeforeHandle(({ query: { name }, status }) => { | ||
| if(!name) return status(401) | ||
| if(!name) return status("Unauthorized") |
There was a problem hiding this comment.
Replace hard tab with spaces for consistent indentation.
The line uses a hard tab at the start, which violates the markdown linting rule MD010. Replace the tab with spaces to align with markdown formatting standards.
- if(!name) return status("Unauthorized")
+ if(!name) return status("Unauthorized")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if(!name) return status("Unauthorized") | |
| if(!name) return status("Unauthorized") |
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
152-152: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In docs/tutorial/getting-started/life-cycle/index.md around line 152, the line
starts with a hard tab which violates MD010; replace the leading tab character
with equivalent spaces (e.g., two or four spaces as used elsewhere in the file)
so the indentation is consistent with the rest of the Markdown document and
passes the linter.
Convert remaining numeric status codes to descriptive strings:
- status(401) → status("Unauthorized") in auth contexts
- status(400) → status("Bad Request") or status("Unauthorized") as appropriate
Files updated:
- docs/index.md (homepage examples)
- docs/integrations/better-auth.md
- docs/tutorial/patterns/extends-context/index.md
- docs/patterns/extends-context.md
- docs/eden/treaty/response.md
braden-w
force-pushed
the
layer-8-remaining-strings
branch
from
7b88bc9 to
db55479
Compare
|
Superseded by #747 (conversions) |
1 participant
This PR completes the conversion of numeric status codes to descriptive string names across the remaining documentation files, building on the work started in PRs #739-#743 and complemented by #745. Together, these changes improve the visibility and readability of string status names throughout the Elysia documentation.
The primary motivation for this change is consistency and self-documentation. Status names like "Unauthorized" and "Bad Request" are immediately readable without requiring developers to recall HTTP status code numbers, making the documentation more accessible and the code more maintainable. This conversion affects the homepage examples, Better Auth integration guide, extends-context pattern documentation, and Eden Treaty response examples.
Some numeric codes were intentionally preserved where they serve a specific purpose. The 418 teapot examples remain numeric with explanatory notes since the teapot status is inherently playful and often referenced by its number. Similarly, 404 codes in routing examples were kept because they're self-explanatory in that context, and migration guides retain their original numeric codes to ensure accurate framework comparison for developers coming from other ecosystems.