blog: improve grammar elysia-14.md #621
Conversation
WalkthroughEdits to Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant Elysia as Elysia App
participant StdSchema as Standard Schema
participant Validator as Validator (Zod/Valibot/...)
participant OpenAPI as OpenAPI Generator
participant xsschema as xsschema (converter)
Dev->>Elysia: Define route + schema (Standard Schema)
Elysia->>StdSchema: Treat Standard Schema as canonical representation
StdSchema->>Validator: Delegate validation to chosen validator(s)
Validator-->>Elysia: Validation result (types inferred)
alt Generate OpenAPI
Elysia->>OpenAPI: Request spec (uses Standard Schema)
opt OpenAPI requires JSON Schema
Elysia->>xsschema: Convert Standard Schema -> JSON Schema
xsschema-->>OpenAPI: JSON Schema for spec
end
OpenAPI-->>Elysia: OpenAPI spec
end
Elysia-->>Dev: Route ready (validation + OpenAPI)
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests
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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/blog/elysia-14.md (1)
77-99: Replace hard tabs with spaces and fix fenced-code spacing in docs/blog/elysia-14.md
- MD010 (hard tabs) present in code blocks — convert tabs to spaces at lines 77–99 and 135–154.
- MD031: add blank line(s) before/after fenced code blocks (issue around line 154).
- Re-run linter to confirm: npx markdownlint-cli2 docs/blog/elysia-14.md (lint currently reports 90 errors).
🧹 Nitpick comments (5)
docs/blog/elysia-14.md (5)
13-13: Align terminology and tense in meta description (Standard Schema; improves ~10%).
- Use “Standard Schema” (not “Standard Validator”) to match the article.
- Switch “Improve” → “Improves” and consider “~10%” to align with the body’s 9–11% phrasing.
- content: Support for Standard Validator. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improve type inference performance by 10%. + content: Support for Standard Schema. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improves type inference performance by ~10%.Repeat the same change for Line 17.
Also applies to: 17-17
114-114: Clarity: tighten wording around OpenAPI type-gen sentence.Minor polish for flow and correctness.
-But if your validator does not support JSON Schema, we provide our unique [OpenAPI type gen](/blog/openapi-type-gen.html) to generate OpenAPI schema directly from TypeScript type from your validator. +But if your validator does not support JSON Schema, we provide [OpenAPI type gen](/blog/openapi-type-gen.html) to generate an OpenAPI schema directly from the TypeScript types produced by your validator.
160-160: Proper noun capitalization: “ReScript Schema”.Brand name is “ReScript”.
-> Using TypeBox, Zod, Valibot, Joi, Yup, ArkType, Effect Schema, TypeMap, and Rescript Schema to validate different parts of the body +> Using TypeBox, Zod, Valibot, Joi, Yup, ArkType, Effect Schema, TypeMap, and ReScript Schema to validate different parts of the body
232-232: Accuracy: avoid “factor of” for percentages.Use “by ~9–11%” instead of “by a factor of ~9–11%”.
-We also managed to improve type inference performance by a factor of ~9-11% and decrease type instantiation by 11.5%, despite the massive increase in type complexity. +We also managed to improve type inference performance by ~9–11% and decrease type instantiation by 11.5%, despite the massive increase in type complexity.
252-253: Tone and preposition fix in “Notable changes” intro.Smoother phrasing and “in 1.3.9” instead of “on 1.3.9”.
-We have closed around 300 issues on 1.3.9, so we don't really have many bug fixes to make for 1.4, as we have solved most of the problems we know. +We closed around 300 issues in 1.3.9, so there aren’t many bug fixes in 1.4—we’ve addressed most known issues.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/blog/elysia-14.md(3 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
docs/blog/elysia-14.md
149-149: Hard tabs
Column: 7
(MD010, no-hard-tabs)
150-150: Hard tabs
Column: 10
(MD010, no-hard-tabs)
151-151: Hard tabs
Column: 1
(MD010, no-hard-tabs)
151-151: Hard tabs
Column: 4
(MD010, no-hard-tabs)
152-152: Hard tabs
Column: 1
(MD010, no-hard-tabs)
152-152: Hard tabs
Column: 4
(MD010, no-hard-tabs)
153-153: Hard tabs
Column: 7
(MD010, no-hard-tabs)
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
docs/blog/elysia-14.md (2)
119-119: Resolved: added missing “use” in Valibot caption.
Matches prior feedback; looks good.
141-154: Replace hard tabs with spaces in docs/blog/elysia-14.mdTabs remain at lines 77–98 and 135–154; markdownlint MD010 may fail CI.
- .post( - '/user/:id', - ({ body }) => body, + .post( + '/user/:id', + ({ body }) => body, @@ - { - body: v.object({ - name: v.literal('lilith') - }) - } - ) + { + body: v.object({ + name: v.literal('lilith') + }) + } + )
🧹 Nitpick comments (10)
docs/blog/elysia-14.md (10)
13-18: Align performance claim with body (10% vs 9–11%/11.57%).
Meta descriptions say “10%,” body says “~9–11%” and “11.57%.” Make meta consistent.- content: Support for Standard Schema. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improves type inference performance by 10%. + content: Support for Standard Schema. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improves type inference performance by ~10%. @@ - content: Support for Standard Schema. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improves type inference performance by 10%. + content: Support for Standard Schema. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improves type inference performance by ~10%.
112-112: Grammar: possessive “Zod’s” and article.- > Using Zod native OpenAPI schema support with **describe** to add description to the schema + > Using Zod's native OpenAPI schema support with **describe** to add a description to the schema
114-121: Standardize product name “OpenAPI Type Gen” and tighten phrasing.-But if your validator does not support JSON Schema, we provide [OpenAPI type gen](/blog/openapi-type-gen.html) to generate OpenAPI schema directly from TypeScript type from your validator. +But if your validator does not support JSON Schema, we provide [OpenAPI Type Gen](/blog/openapi-type-gen.html) to generate OpenAPI schemas directly from your validator’s TypeScript types. -This means that Elysia supports OpenAPI generation for all validators that support Standard Schema, even if they don't directly support JSON Schema. +This means Elysia supports OpenAPI generation for all validators that support Standard Schema, even if they don't directly support JSON Schema. -Not only will it generate the correct input type, but OpenAPI type gen will also generate all possible output types, including error responses. +Not only will it generate correct input types, but OpenAPI Type Gen will also generate all possible output types, including error responses.
174-174: Tighten wording; “effortlessly” clashes with “nearly impossible.”-The versatility of Macro is truly amazing, letting you do things that are nearly impossible with other frameworks, effortlessly. +The versatility of Macro is truly amazing, letting you do things that are nearly impossible with other frameworks.
186-186: Consistency: “Standard Schema,” not “Standard Validator.”-You can also stack multiple schemas from different macros, or even from Standard Validator, and they will work together seamlessly. +You can also stack multiple schemas from different macros, or even from Standard Schema, and they will work together seamlessly.
189-189: Style: avoid all-caps “BUT.”-Macro schema also supports type inference for **lifecycle within the same macro** **BUT** only with a named single macro due to a TypeScript limitation. +Macro schema also supports type inference for **lifecycle within the same macro**, but only with a named single macro due to a TypeScript limitation.
212-215: Pluralize “detail(s)” and fix verb agreement.-You can now define OpenAPI detail for your macro, allowing you to add more detail to your OpenAPI documentation directly from your macro. +You can now define OpenAPI details for your macro, allowing you to add more detail to your OpenAPI documentation directly from your macro. -If the route already has OpenAPI detail, it will merge the detail together but prefers the route detail over macro detail. +If the route already has OpenAPI details, it will merge the details together but prefer the route details over macro details.
231-231: Pluralize and clarify reason.-> Type Soundness covers all lifecycle events and macros, allowing you to have complete documentation of your API. The only exception is an inline lifecycle event due to slowness. +> Type Soundness covers all lifecycle events and macros, allowing you to have complete documentation of your API. The only exception is inline lifecycle events due to performance.
253-254: Remove duplicated “so”.-We closed around 300 issues in 1.3.9, so so there aren’t many bug fixes in 1.4—we’ve addressed most known issues. +We closed around 300 issues in 1.3.9, so there aren’t many bug fixes in 1.4—we’ve addressed most known issues.
262-262: Grammar: plural subject and avoid double “by default.”-ObjectString/ArrayString no longer produces default values by default due to security reasons +ObjectString/ArrayString no longer produce default values due to security reasons
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/blog/elysia-14.md(4 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
docs/blog/elysia-14.md
141-141: Hard tabs
Column: 1
(MD010, no-hard-tabs)
142-142: Hard tabs
Column: 1
(MD010, no-hard-tabs)
143-143: Hard tabs
Column: 1
(MD010, no-hard-tabs)
149-149: Hard tabs
Column: 1
(MD010, no-hard-tabs)
150-150: Hard tabs
Column: 1
(MD010, no-hard-tabs)
151-151: Hard tabs
Column: 1
(MD010, no-hard-tabs)
152-152: Hard tabs
Column: 1
(MD010, no-hard-tabs)
153-153: Hard tabs
Column: 1
(MD010, no-hard-tabs)
154-154: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (1)
docs/blog/elysia-14.md (1)
43-44: Headline rewrite reads clearly and sets focus.
Good call centering on Standard Schema and Type Soundness.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (12)
docs/blog/elysia-14.md (12)
13-18: Align performance figures (10% vs 9–11%).Front-matter says “Improves … by 10%,” while the body claims “~9–11%.” Pick one and use it consistently (suggest “~10%” in front-matter).
Apply:
- content: Support for Standard Schema. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improves type inference performance by 10%. + content: Support for Standard Schema. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improves type inference performance by ~10%.- content: Support for Standard Schema. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improves type inference performance by 10%. + content: Support for Standard Schema. Macro with schema, extension, and OpenAPI detail. Lifecycle type soundness. Improves type inference performance by ~10%.
41-41: Tighten phrasing about the song credit.-Named after the song [Supersymmetry](https://youtu.be/NYyjQjtbteA) by Sta, a Tone Sphere ending theme. +Named after the song [Supersymmetry](https://youtu.be/NYyjQjtbteA) by Sta, an ending theme of Tone Sphere.
112-112: Format identifier and article.-> Using Zod's native OpenAPI schema support with **describe** to add description to the schema +> Using Zod's native OpenAPI schema support with `describe` to add a description to the schema
114-116: Pluralize “type(s)” for correctness.-But if your validator does not support JSON Schema, we provide [OpenAPI type gen](/blog/openapi-type-gen.html) to generate OpenAPI schema directly from TypeScript type from your validator. +But if your validator does not support JSON Schema, we provide [OpenAPI type gen](/blog/openapi-type-gen.html) to generate OpenAPI schema directly from the TypeScript types of your validator.-This means Elysia supports OpenAPI generation for all validators that support Standard Schema, even if they don't directly support JSON Schema. +This means Elysia supports OpenAPI generation for all validators that support Standard Schema, even if they don't directly support JSON Schema.
121-123: Pluralize “input type”.-Not only will it generate correct input type, but OpenAPI type gen will also generate all possible output types, including error responses. +Not only will it generate correct input types, but OpenAPI type gen will also generate all possible output types, including error responses.
188-196: Lowercase “BUT” and simplify guidance.-Macro schema also supports type inference for **lifecycle within the same macro** **BUT** only with a named single macro due to a TypeScript limitation. +Macro schema also supports type inference for lifecycle within the same macro, but only when you use a single, named macro due to a TypeScript limitation.-If you want to use lifecycle type inference within the same macro, you should use a named single macro instead of multiple stacked macros. +If you need lifecycle type inference within the same macro, use a single, named macro rather than multiple stacked macros.-> Not to be confused with using macro schema to infer types into a route's lifecycle event. That works just fine—this limitation only applies to using lifecycle within the same macro. +> Not to be confused with using macro schema to infer types into a route's lifecycle event. That works just fine—this limitation applies only to lifecycle within the same macro.
212-215: Use “details” and clarify precedence.-You can now define OpenAPI detail for your macro, allowing you to add more detail to your OpenAPI documentation directly from your macro. +You can now define OpenAPI details for your macro, allowing you to add more details to your OpenAPI documentation directly from your macro.-If the route already has OpenAPI detail, it will merge the detail together but prefers the route detail over macro detail. +If the route already has OpenAPI details, they will be merged, preferring the route‑level details over macro‑level details.
222-225: Clean up wording and avoid duplication.-By refactoring over 3,000+ lines of pure types, reconciling response status types, including unit tests at the type level for all lifecycle APIs to ensure type integrity, and optimizing type performance, we made sure that type inference doesn't get slower. +By refactoring over 3,000 lines of pure types, reconciling response status types, adding type‑level unit tests for all lifecycle APIs, and optimizing type performance, we ensured that type inference didn't get slower.Optionally remove the next sentence (Line 224) as it repeats the prior idea.
-All of these complex achievements allow us to document all possibilities of what a single route can return.
231-231: Minor phrasing polish.-> Type Soundness covers all lifecycle events and macros, allowing you to have complete documentation of your API. The only exception is inline lifecycle events due to performance. +> Type Soundness covers all lifecycle events and macros, allowing you to have complete documentation of your API. The only exception is inline lifecycle events for performance reasons.
247-247: Add article for smoother reading.-> `group` with schema will coexist with route schema +> `group` with schema will coexist with the route schema
263-264: Grammar nits in “Changes”.-- ObjectString/ArrayString no longer produce default values due to security reasons +- ObjectString/ArrayString no longer produce default values for security reasons-- Cookie now dynamically parses when format is likely JSON +- Cookie now dynamically parses when the format is likely JSON
276-276: Reduce repetition in “cover art” sentence.-Our cover art mirrors the theme of the Supersymmetry (music) cover art, where ElysiaJS chan is mirroring Weirs with a similar pose. +Our cover art mirrors the theme of the Supersymmetry cover, with ElysiaJS chan mirroring Weirs in a similar pose.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/blog/elysia-14.md(4 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
docs/blog/elysia-14.md
141-141: Hard tabs
Column: 1
(MD010, no-hard-tabs)
142-142: Hard tabs
Column: 1
(MD010, no-hard-tabs)
143-143: Hard tabs
Column: 1
(MD010, no-hard-tabs)
149-149: Hard tabs
Column: 1
(MD010, no-hard-tabs)
150-150: Hard tabs
Column: 1
(MD010, no-hard-tabs)
151-151: Hard tabs
Column: 1
(MD010, no-hard-tabs)
152-152: Hard tabs
Column: 1
(MD010, no-hard-tabs)
153-153: Hard tabs
Column: 1
(MD010, no-hard-tabs)
154-154: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (1)
docs/blog/elysia-14.md (1)
101-101: LGTM: Clear, user-focused promise.
| .post( | ||
| '/user/:id', | ||
| ({ body }) => body, | ||
| // ^? | ||
|
|
||
|
|
||
|
|
||
| { | ||
| body: v.object({ | ||
| name: v.literal('lilith') | ||
| }) | ||
| }) | ||
|
|
||
| { | ||
| body: v.object({ | ||
| name: v.literal('lilith') | ||
| }) | ||
| } | ||
| ) | ||
| ``` |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Replace hard tabs with spaces (markdownlint MD010).
Tabs here will fail lint/CI. Convert to spaces-only indentation.
- .post(
- '/user/:id',
- ({ body }) => body,
+ .post(
+ '/user/:id',
+ ({ body }) => body,
// ^?
- {
- body: v.object({
- name: v.literal('lilith')
- })
- }
- )
+ {
+ body: v.object({
+ name: v.literal('lilith')
+ })
+ }
+ )Run to confirm no tabs remain:
🏁 Script executed:
#!/bin/bash
rg -nP '\t' docs/blog/elysia-14.md || echo "No hard tabs found"Length of output: 590
Replace hard tabs with spaces in docs/blog/elysia-14.md
Tabs detected at lines 77–98 and 135–154 — convert all tabs to spaces-only indentation (markdownlint MD010) to avoid CI failures.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
141-141: Hard tabs
Column: 1
(MD010, no-hard-tabs)
142-142: Hard tabs
Column: 1
(MD010, no-hard-tabs)
143-143: Hard tabs
Column: 1
(MD010, no-hard-tabs)
149-149: Hard tabs
Column: 1
(MD010, no-hard-tabs)
150-150: Hard tabs
Column: 1
(MD010, no-hard-tabs)
151-151: Hard tabs
Column: 1
(MD010, no-hard-tabs)
152-152: Hard tabs
Column: 1
(MD010, no-hard-tabs)
153-153: Hard tabs
Column: 1
(MD010, no-hard-tabs)
154-154: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In docs/blog/elysia-14.md around lines 77–98 and 135–154, the file contains hard
tab characters used for indentation which triggers markdownlint MD010; replace
all tabs in those ranges (and any other tabs in the file) with spaces
(preferably 2 or 4 spaces per indent consistent with the project style) so the
markdown uses spaces-only indentation and CI linting will pass.
Summary by CodeRabbit