New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: custom lints #548
Labels
feature
A new feature or request
Comments
I've implemented the lints (without fixes yet). |
7 tasks
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
As a developer, I want to be able to have custom lint rules specifically for Dart Frog so that I can see warnings and apply quick fixes directly from my IDE rather than waiting for runtime errors.
Huge thanks to @Ehesp @Salakar @rrousselGit for initiating the convo and proposing the first batch of lints!
Requirements
Proposed Lint Rules
A route file must have an onRequest handler:
Currently you can just make an empty file, and the dev server will error since
onRequest
does not existonRequest
mustreturn FutureOr<Response>
You can just return anything at the moment, nothing will complain but the dev server will error out again,
onRequest
must contain aRequestContext
You can add anything in right now, nothing will complain but the dev server will error out again,
A dynamic route path must contain the path params
The path:
routes/posts/[userId]/[postId].dart
must contain anonRequest
handler with dynamic args:Route conflicts: https://dartfrog.vgv.dev/docs/basics/routes#route-conflicts-
Rouge routes: https://dartfrog.vgv.dev/docs/basics/routes#rogue-routes-
Middleware files should contain a valid middleware handler:
All of the same arguments as above apply here; return a
Handler
, contains a handler, must have a function calledmiddleware
etcValidation on a custom server handler
Same ideas as above, but in regards to the
run
method within amain.dart
file: https://dartfrog.vgv.dev/docs/advanced/custom_entrypointValidation on middleware chaining
It’s fairly common for developers to apply the cascade operator on middleware when calling handler.use but this leads to incorrect behavior since use returns a new handler
The text was updated successfully, but these errors were encountered: