docs(migrate): highlight Elysia string status name advantage#745
docs(migrate): highlight Elysia string status name advantage#745braden-w wants to merge 3 commits intoelysiajs:mainfrom
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 28 minutes and 42 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 (4)
✨ 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 |
Adds tip boxes to all migration guides highlighting that Elysia supports both numeric and string status names, unlike Express/Fastify/Hono which only accept numeric codes. This is a genuine DX advantage worth showcasing to users migrating from other frameworks.
braden-w
force-pushed
the
layer-9-migration-guides
branch
from
32ce779 to
b9f5ef7
Compare
1 participant
This change highlights one of Elysia's developer experience advantages for developers migrating from Express, Fastify, and Hono. While those frameworks require numeric HTTP status codes like
res.status(404), Elysia supports both numeric codes and human-readable string names likeset.status = 'Not Found'. This makes code more readable and reduces the need to memorize status code numbers, which is a genuine improvement worth surfacing to potential migrants.To accomplish this, I added tip boxes to the Express, Fastify, and Hono migration guides that explicitly call out this dual support. The tRPC migration guide frames this feature differently since tRPC already uses string-based error codes, making the transition to Elysia's string status names feel more natural. This builds on PRs #739-#744, which also improved visibility of string status name support throughout the documentation.