feat(server): dev safety checks

[mbhrznr]

closes #1416
closes #1524

as discussed in the aforementioned issue, @deer was so kind to let me finish this one off.
as expected it gave me quite some nice understanding of fresh's internals.

this pr introduces the following check when being in dev mode:

• only one _app.tsx is allowed per application and it must have default export
• one 500.tsx and it must have default export
• one 404.tsx and it must have default export
• pascal case or kebab case islands (island name) (this one became obsolete w/ 1.3)
• route must have handler or component
• route patterns must be unique
• if static override, ensure there is no normal static directory
• static file conflict with routes (because static files have higher priority)
• plugin doesn't call render
• plugin each defined module must be a js/ts module

the functionality can be tested by navigating into tests/fixture_dev_checks/ and running deno task start

[deer]

Thanks for finishing this up. Looks pretty good, but I wonder if we want to specifically create a union type for all the categories and then reference them as something like this:

return [{
      category: DevChecks.ModuleExport,
      message: `Your ${moduleName} file does not have a default export.`,
      fileLink: moduleName,
    }];

instead of

return [{
      category: "Module Export",
      message: `Your ${moduleName} file does not have a default export.`,
      fileLink: moduleName,
    }];

Additionally, what about implementing the check in #1414? And taking the tests as well. Then I can just close that one, and a maintainer can close #539. And then you can resolve three issues at once (the two you mention, plus 475 which I was going to resolve).

[mbhrznr]

@deer thanks for the suggestion. will incorporate everything you mentioned!

[marvinhagemeister]

LGTM, thanks for adding these 🎉

[marvinhagemeister]

Apologies for the churn. I merged the PR too quickly and it's currently blocking me on feature work, so I've reverted it in #1567. So far I encountered that the handlers rule doesn't account for them being an array.

The output is a bit messy when there are multiple errors. Maybe some visual hierarchy via colors can help?

Most rules don't print the file name where the error happened which makes it difficult to track down where the error is coming from. The route.name property that many rules rely on is not the file name.