Trunk is slowing down the project

[andreilgeorgescu]

This will be a comprehensive revamping of many loosely related aspects of this project that will improve development:

• Linting/Formatting
  • Currently ESLint and Prettier handle this for all astro/js/jsx files and this is a problem due to how slow they are. The solution is to use Biome to handle all js/jsx files as well as the frontmatter of astro files (the rest is not currently supported). ESLint is ~35x faster than prettier and has arguably better rules than eslint/prettier.
  • More trunk linters/formatters should be enabled to comprehensively support this repository
  • Auto fixing should be enabled upon pre-push checks, which will then be enabled in all scenarios instead of only interactive ones
  • Unnecessary actions like upgrade announcements should be disabled in favor of CI weekly upgrades
  • Astro check should be moved from being called in every build (which slows down cloudflare builds) and instead be done pre-push and pre-merge in a merge queue
  • Modifying the package.json should automatically update node_modules
• Development Environment
  • A substantial amount of helpful extensions are not enabled with the assumption that they are already being used. They should all be explicitly listed in the devcontainer
  • Trunk will still be exposed through NPM for people not using codespaces but it is not an ideal situation
  • The settings file should be revamped to have better defaults and handle most of the extension setup. It is is all in one file to again work for people not using codespaces.
  • An .editorconfig should be used to act as a source of truth for all linters/formatters that support it as well as vscode itself. It can also be used for people not using vscode.
• Markdown
  • Code support is rudimentary and should be upgraded to support more modern features like code highlighting and code copying through something like Expressive Code
  • Indenting should be set to a more standard and cleaner 4 spaces. However, the issue with this is that this will also indent code blocks. The best solution would likely be to move code to its own file and then support formatting/linting for said files but this might be untenable so an alternative solution is to simply disable formatting of embedded code.
  • There are a number of issues regarding the way markdown is currently written regarding newlines.