Skip to content

einSelbst/overnext

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Overnext - Overly Opinionated Next.js Boilerplate

GitHub Workflow Status Continuous integration GitHub Super-Linter FOSSA Status

Vercel Netlify Status

Tooling

Prettier Commitizen friendly Renovate

Versions

next version react version webpack version @babel/core version typescript version cypress version jest version eslint version tailwindcss version

Metrics

Bugs Code Smells Lines of Code Maintainability Rating Quality Gate Status Reliability Rating Security Rating Technical Debt Vulnerabilities

Total alerts Language grade: JavaScript

Code Grade

Approach

  • DX first
    • the foundation
  • Integrations second
    • db/cms
    • Third-party services
  • UI third
    • all screens: from watch-face to wide screen, not just mobile/desktop
    • the new responsive
  • UX last
    • features & content

This is more about priorities than about a temporal order.

Guiding Principles

  • automate it ™
  • optimize it, do it cheap
  • go vanilla until good reasons to not
  • test & lint it, to catch bugs early
  • manage tech dept

DX

  • pnpm package manager

  • automation, inspirations

  • conformity, inspirations

  • standard-version for release versioning and changlog creation

  • browserlist for browser compatibility

  • enable expiring ToDo's (`eslint-plugin-unicorn`)
    • Expire after a specific date: [YYYY-MM-DD] to define a UTC due date in the ISO 8601 format
    • Expire when your package (package.json) reaches a specific version: [>1] or [>=2]. No whitespace.
    • Expire when a package.json engines property reaches a specific version: [engine:node@>8] or [engine:node@>=8], only node engine is supported. No whitespace.
    • Expire when you install/uninstall a specific package: use [+package] or [-package] to expire. No whitespace.
    • Expire when a package reaches a specific version: use [package@>1] or [package@>=2]. No whitespace.

Tips

Commit Style

  • Conventional Commits convention

    • Commitizen CLI helper

      Show commit types
      • a11y: Accessibility
      • build: Changes that affect the build tooling (example scopes: webpack, TypeScript, pnpm)
      • chore: Other changes that don't modify src or test files
      • ci: Changes to the CI configuration files and scripts (example scopes: GitHub Actions, BrowserStack)
      • cx: Customer Experience
      • deps: Managing dependencies
      • docs: Documentation only changes
      • dx: All things about improving developer experience
      • feat: A new feature
      • fix: A bugfix
      • i18n: Internationalization
      • perf: A code change that improves performance
      • refactor: A code change that neither fixes a bug nor adds a feature
      • revert: Reverts a previous commit
      • style: Changes that do not affect the meaning of the code (whitespace, formatting, missing semi-colons, etc)
      • test: Adding missing tests or correcting existing tests
      • ui: CSS and layout
      • ux: User Experience
      • wip: work in progress
    • semantic-pull-requests GitHub app

Scripts

To print a description of the scripts run pnpm run info

dev: Start next app in dev mode
debug: Start node debugger
build: Build the app
start: Start server to serve the local app build
serve: Build app and start server
servex: Build & run app on public URL
test: Run unit and integration tests once
test:ci: Run jest tests on CI, will re-add cypress later again
test:jest: Run jest tests and update screenshots
test:cy: Open cypress test runner (needs a running app server)
e2e:watch: Start dev server, open cypress and watch
e2e: Build & serve app, then run cypress once
format: Format source code and fix issues
lint: Lint source code
lint:fix: Use deamon to lint source code and fix issues
lint:html: Run html-validate on generated static output files
lint:css: Run stylelint on source code to lint CSS
checklinks: Test integrity of hyperlinks in the build files
checklinks:server: Test integrity of hyperlinks on the local server
validate: Validate source code and output files
validate:src: Format, lint, type-check & unit test the app
validate:out: Build app, run integration tests, check links & validate generated html
build:analyze: Build app and output bundle analyzer diagrams
build:size: build app and measure loading performance
size: Run size-limit
size:why: Run size-limit and open statoscope report in browser
audit:fix: Check vulnerabilities in production package and try to fix them
find:unused: Find unused files
build:ssr: used on CI for 'compressed size' action
cz: Make new commit
release: Prepare a new release
docs: Generate typedoc docs
info: Display info about the scripts
stylelint-check: Check stylelint for rules conflicting prettier

Code Style

Linter / A11y

Potentially interesting

Tech Stack

  • next.js, who would have thought
  • production deployment (& a test branch with another setup) with preact, btw inferno is not compatible with nextjs
  • Sentry for error monitoring
  • FaunaDB
  • WIP: sanity
  • TODO: React Query

Afternext

Next.js Configuration

Features in use

Plugins & Helper

Styling

...all still unclear atm...

Testing

CI

GitHub Actions

WIP Security Audits

Audits & Service Dashboards

Installation

see CONTRIBUTING

Deployment

Demo

Monitoring

Documentation

ToDo Documentation

Learnings

prop-types

Intially I wanted to use prop-types because of the reasons given in those articles:

When I actually started using them I had some problems:

  • to be able to extend the function object I had to use React.FC because otherwise TypeScript prevents this, but:
  • I don't want to use React.FC for these reasons,
    • especially I don't want to close the door for going Preact
  • also prop-types itself seem to have an unclear future

I might still use prop-types in case I encounter a situation where I get much benefit from the runtime type checking, but then I would only use it for this specific case.

TypeScript Barrel

Using an index.ts file to bundle multiple submodules is called 'Barreling'. This can cause circular dependency issues as it happened to me because I was using the env.config inside of seo.config. Also it might affect webpack's ability to chunk the code.

Linter

Initially I used Prettier-Standard which included

  • Standard
  • PrettierX because I thought it's a great idea to not waste time for config etc. But the tool hasn't received any maintenance for almost a year and I already had to add workarounds. Being interested in linting in general I also had issues with clean extensibility of my ESLint config and it wasn't completely clear to me what really runs as part of prettier-standard.

I also considerd other bundles like:

but they all have stuff included I don't need and other stuff is missing which I want so I decided to go vanilla eslint and do my config by hand to have max control over everything and Less dependencies.

Hosting

There are a few differences between Vercel & Netlify.

  • sass module can be a devDependency on Netlify, but must be a (production) dependency on Vercel
  • i18n routing: on Vercel the user is redirected to the browser detected language by default, but not on Netlify

Setup

ToDo

API Reference

ToDo link to API Docs

Roadmap

  • integrate Sanity
  • integrate React Query
  • integrate React Hook Form
  • integrate ajv

Optimizations

Credits

...where credits due, thanks to @bahmutov, @elliottsj, Stefan Baumgartner, @ferlopezm94,@iamvishnusankar, @pacocoursey, @thomaseizinger, @sindresorhus and all the others whom I copied code from!

Related

ToDo

I should use GitHub Issues for this but hey.

  • I have Node.js version defined in several places, maybe I can consolidate this
    • .nvmrc
    • .npmrc because pnpm
    • package.json > engine, removed because annoying warning in vercel
    • package.json > volta, for volta
  • add SRI
  • cypress a11y plugin
  • cypress-html-validate plugin
  • make use of Project Wallace, still wip
  • wdyr vs preact 1
  • use ISR - Incremental Static Regeneration ? opinion

Documentation ToDo's

Project Automation / Labeling Ideas

Issues

Projects

Milestones

Branches

Pull Requests

Licenses

FOSSA Status