wip

.eslintrc.yml

@@ -11,10 +11,10 @@ extends:
   - prettier
 rules:
   consistent-return: off # When enabled, it makes it impossible to use early returns without explicitly returning undefined
-#  react/function-component-definition:
-#    - error
-#    - namedComponents: arrow-function
-#      unnamedComponents: arrow-function
+  #  react/function-component-definition:
+  #    - error
+  #    - namedComponents: arrow-function
+  #      unnamedComponents: arrow-function
   react/jsx-props-no-spreading: off # Prop types already protect against passing invalid or unnecessary props down to components.
   unicorn/filename-case: off
   unicorn/prevent-abbreviations:

.prettierrc.yml

@@ -1,23 +1,17 @@
 singleQuote: true
 printWidth: 100
+proseWrap: always
 importOrder:
   - '^(react/(.*)$)|^(react$)'
   - '^(next/(.*)$)|^(next$)'
   - '<THIRD_PARTY_MODULES>'
   - ''
   - '^types$'
   - '^@/types/(.*)$'
-  - '^@/features/common/(.*)$'
-  - '^@/features/(.*)$'
-  - '^@/server/(.*)$'
   - '^@/styles/(.*)$'
   - '^@/(.*)$'
   - '^[./]'
-importOrderSortSpecifiers: true
-importOrderBuiltinModulesToTop: true
-importOrderMergeDuplicateImports: true
-importOrderCombineTypeAndValueImports: true
-pluginSearchDirs: false
+importOrderTypeScriptVersion: 5.4.3
 plugins:
   - '@ianvs/prettier-plugin-sort-imports'
-  - 'prettier-plugin-tailwindcss'
+  - 'prettier-plugin-tailwindcss' # Must come last

README.md

@@ -1,7 +1,7 @@
 # Web App Template
 
-This is a complete template for building web apps. It's primarily intended for my own usage.
-I use it to gather my learnings and opinions on best practices and configurations.
+This is a complete template for building web apps. It's primarily intended for my own usage. I use
+it to gather my learnings and opinions on best practices and configurations.
 
 ## Setup
 
@@ -96,7 +96,8 @@ $ pnpm lint
 Staged files are automatically linted before commits. Be sure to **fix all linting errors before
 committing**.
 
-We recommend using an [editor integration for ESLint](https://eslint.org/docs/user-guide/integrations).
+We recommend using an
+[editor integration for ESLint](https://eslint.org/docs/user-guide/integrations).
 
 ### Code Formatting
 
@@ -225,9 +226,11 @@ production environment.
 
 We use Architectural Decision Records (ADRs) for documenting architectural significant decisions.
 
-To learn more about ADRs and browse them, check out [our architectural decision log](https://adr.web-app-template.igassmann.me/).
+To learn more about ADRs and browse them, check out
+[our architectural decision log](https://adr.web-app-template.igassmann.me/).
 
-To learn how to write a new ADR, check out [docs/architectural-decisions/README.md](./docs/architectural-decisions/README.md).
+To learn how to write a new ADR, check out
+[docs/architectural-decisions/README.md](./docs/architectural-decisions/README.md).
 
 ### Data Tracking Plan
 

docs/api-guidelines.md

@@ -6,10 +6,9 @@ APIs built by Igor Gassmann must follow this document.
 
 All names specified in path and query parameters, resource names, and JSON input and output fields
 and pre-defined values must use verbose naming patterns and must not use abbreviations other than
-acronyms that are the dominant mode of expression in the domain being represented by the API,
-(e.g. URL). Acronyms and initialisms should always be all capitalized or all lowercased. Names
-should be in correct American English. For example, license (instead of licence),
-color (instead of colour).
+acronyms that are the dominant mode of expression in the domain being represented by the API, (e.g.
+URL). Acronyms and initialisms should always be all capitalized or all lowercased. Names should be
+in correct American English. For example, license (instead of licence), color (instead of colour).
 
 ## Endpoints
 
@@ -27,7 +26,8 @@ Bad:
 
 ### Resource Nesting
 
-Nesting of resources should be avoided. [This article](https://www.moesif.com/blog/technical/api-design/REST-API-Design-Best-Practices-for-Sub-and-Nested-Resources/)
+Nesting of resources should be avoided.
+[This article](https://www.moesif.com/blog/technical/api-design/REST-API-Design-Best-Practices-for-Sub-and-Nested-Resources/)
 goes in depth on their problems.
 
 If a resource relation can only exist within another resource, sub-resources should be employed.
@@ -49,7 +49,8 @@ Example:
 
 ### Filtering
 
-Use a unique query parameter for each field that implements filtering. [LHS brackets](https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/#lhs-brackets)
+Use a unique query parameter for each field that implements filtering.
+[LHS brackets](https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/#lhs-brackets)
 should be used to indicate operators.
 
 Example:
@@ -81,9 +82,10 @@ Example:
 
 Pagination can be used to split the results of a query into pages. The API should use
 [cursor-based pagination](https://developers.facebook.com/docs/graph-api/using-graph-api/#paging).
-Pagination details should be included using the [Link header introduced by RFC 5988](https://tools.ietf.org/html/rfc5988#page-6).
-The Link header can return a set of ready-made links, so the API consumer doesn't have to construct
-links themselves.
+Pagination details should be included using the
+[Link header introduced by RFC 5988](https://tools.ietf.org/html/rfc5988#page-6). The Link header
+can return a set of ready-made links, so the API consumer doesn't have to construct links
+themselves.
 
 Example:
 
@@ -147,22 +149,23 @@ sub-resources. `PUT` should also avoid query parameters.
 
 `PATCH` has been standardized by IETF as the method to be used for updating an existing object
 incrementally (see [RFC 5789](https://tools.ietf.org/html/rfc5789)). `PATCH` methods should only
-support partial objects to only update parts of a resource. This is [JSON Merge Patch](https://tools.ietf.org/html/rfc7396),
-a specialized media type `application/merge-patch+json` that is a partial resource representation.
+support partial objects to only update parts of a resource. This is
+[JSON Merge Patch](https://tools.ietf.org/html/rfc7396), a specialized media type
+`application/merge-patch+json` that is a partial resource representation.
 
 ### DELETE
 
-`DELETE` requests are used to delete resources. The semantic is best described as "please delete
-the resource identified by the URL".
+`DELETE` requests are used to delete resources. The semantic is best described as "please delete the
+resource identified by the URL".
 
 `DELETE` requests are usually applied to single resources, not on collection resources, as this
 would imply deleting the entire collection.
 
 Successful `DELETE` requests will usually generate 200 (if the deleted resource is returned) or 204
 (if no content is returned).
 
-Failed `DELETE` requests will usually generate 404 (if the resource cannot be found) or 410
-(if the resource was already deleted before).
+Failed `DELETE` requests will usually generate 404 (if the resource cannot be found) or 410 (if the
+resource was already deleted before).
 
 ## Actions
 
@@ -203,7 +206,8 @@ Bad:
 
 ### Pretty-Print Responses
 
-Results should be pretty-printed by default. The data overhead, with gzip enabled, [is negligible](http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#pretty-print-gzip).
+Results should be pretty-printed by default. The data overhead, with gzip enabled,
+[is negligible](http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#pretty-print-gzip).
 
 ## Dates
 
@@ -222,8 +226,8 @@ time zones they accept (any valid time zone should be accepted), for example
 
 5xx errors should be only for server errors and uptime failures — there should be no repeatable way
 for users to generate 5xx error codes. 4xx errors should be used when the failure is a result of
-incorrect or unsupported user input. Standard HTTP status codes should be used; see the [HTTP Status
-Code definitions](https://httpstatuses.com/) for more information.
+incorrect or unsupported user input. Standard HTTP status codes should be used; see the
+[HTTP Status Code definitions](https://httpstatuses.com/) for more information.
 
 ### Error JSON Objects
 
@@ -252,9 +256,9 @@ be subject to version control and placed inside the `docs/` directory of the cor
 
 ## Rate Limiting
 
-To prevent abuse, it is standard practice to add some sort of rate limiting to an API. [RFC 6585](http://tools.ietf.org/html/rfc6585#section-4)
-introduced an HTTP status code [429 Too Many Requests](https://tools.ietf.org/html/rfc6585) to
-accommodate this.
+To prevent abuse, it is standard practice to add some sort of rate limiting to an API.
+[RFC 6585](http://tools.ietf.org/html/rfc6585#section-4) introduced an HTTP status code
+[429 Too Many Requests](https://tools.ietf.org/html/rfc6585) to accommodate this.
 
 We should include the following headers:
 

docs/architectural-decisions/20211230-use-markdown-architectural-decision-records.md

@@ -5,25 +5,27 @@
 
 ## Context and Problem Statement
 
-We want to record architectural decisions made in this project.
-Which format and structure should these records follow?
+We want to record architectural decisions made in this project. Which format and structure should
+these records follow?
 
 ## Considered Options
 
 - [MADR](https://adr.github.io/madr/) 2.1.2 with Log4brains patch
 - [MADR](https://adr.github.io/madr/) 2.1.2 – The original Markdown Architectural Decision Records
-- [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) – The first incarnation of the term "ADR"
-- [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) – The Y-Statements
+- [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions)
+  – The first incarnation of the term "ADR"
+- [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions)
+  – The Y-Statements
 - Other templates listed at <https://github.com/joelparkerhenderson/architecture_decision_record>
 - Formless – No conventions for file format and structure
 
 ## Decision Outcome
 
 Chosen option: "MADR 2.1.2 with Log4brains patch", because
 
-- Implicit assumptions should be made explicit.
-  Design documentation is important to enable people understanding the decisions later on.
-  See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940).
+- Implicit assumptions should be made explicit. Design documentation is important to enable people
+  understanding the decisions later on. See also
+  [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940).
 - The MADR format is lean and fits our development style.
 - The MADR structure is comprehensible and facilitates usage & maintenance.
 - The MADR project is vivid.
@@ -32,6 +34,7 @@ Chosen option: "MADR 2.1.2 with Log4brains patch", because
 
 The "Log4brains patch" performs the following modifications to the original template:
 
-- Change the ADR filenames format (`NNN-adr-name` becomes `YYYYMMDD-adr-name`), to avoid conflicts during Git merges.
+- Change the ADR filenames format (`NNN-adr-name` becomes `YYYYMMDD-adr-name`), to avoid conflicts
+  during Git merges.
 - Add a `draft` status, to enable collaborative writing.
 - Add a `Tags` field.

docs/architectural-decisions/20221123-use-nextjs.md

@@ -6,8 +6,8 @@
 
 ## Context and Problem Statement
 
-We need a way to build a web application. We want to use a framework that is well-supported and
-that we can bet on for the long term. Which framework should we use?
+We need a way to build a web application. We want to use a framework that is well-supported and that
+we can bet on for the long term. Which framework should we use?
 
 ## Decision Drivers
 
@@ -65,4 +65,5 @@ It's maintained by Facebook.
 - Good, because of its popularity
 - Good, because it's easy to get started
 - Bad, because it doesn't come with routing and server-side rendering
-- Bad, because [their own documentation says it's not the best choice for production apps](https://reactjs.org/learn/start-a-new-react-project#building-with-a-full-featured-framework)
+- Bad, because
+  [their own documentation says it's not the best choice for production apps](https://reactjs.org/learn/start-a-new-react-project#building-with-a-full-featured-framework)

docs/architectural-decisions/README.md

@@ -22,7 +22,8 @@ To create a new ADR, run the following command:
 $ pnpm adr:new
 ```
 
-This will create a new ADR file in `docs/architectural-decisions` and open it in your default editor.
+This will create a new ADR file in `docs/architectural-decisions` and open it in your default
+editor.
 
 ### Listing ADRs
 
@@ -40,4 +41,5 @@ To preview the architectural decision log locally, run the following command:
 $ pnpm adr:preview
 ```
 
-In preview mode, the Hot Reload feature is enabled: any change you make to a markdown file is applied live in the UI.
+In preview mode, the Hot Reload feature is enabled: any change you make to a markdown file is
+applied live in the UI.

docs/architectural-decisions/index.md

@@ -3,16 +3,19 @@ You are free to edit it as you want -->
 
 # Architectural Decision Log
 
-Welcome 👋 to the architectural decision log of this project.
-You will find here all the Architecture Decision Records (ADRs) of this project.
+Welcome 👋 to the architectural decision log of this project. You will find here all the
+Architecture Decision Records (ADRs) of this project.
 
 ## Definition and purpose
 
-> An Architectural Decision (AD) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant.
-> An Architectural Decision Record (ADR) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitutes its decision log.
+> An Architectural Decision (AD) is a software design choice that addresses a functional or
+> non-functional requirement that is architecturally significant. An Architectural Decision Record
+> (ADR) captures a single AD, such as often done when writing personal notes or meeting minutes; the
+> collection of ADRs created and maintained in a project constitutes its decision log.
 
-An ADR is immutable: only its status can change (i.e., become deprecated or superseded). That way, you can become familiar with the whole project history just by reading its decision log in chronological order.
-Moreover, maintaining this documentation aims at:
+An ADR is immutable: only its status can change (i.e., become deprecated or superseded). That way,
+you can become familiar with the whole project history just by reading its decision log in
+chronological order. Moreover, maintaining this documentation aims at:
 
 - 🚀 Improving and speeding up the onboarding of a new team member
 - 🔭 Avoiding blind acceptance/reversal of a past decision
@@ -22,9 +25,10 @@ Moreover, maintaining this documentation aims at:
 
 ## Usage
 
-This website is automatically updated after a change on the `main` branch of the project's Git repository.
-In fact, the developers manage this documentation directly with markdown files located next to their code, so it is more convenient for them to keep it up-to-date.
-You can browse the ADRs by using the left menu or the search bar.
+This website is automatically updated after a change on the `main` branch of the project's Git
+repository. In fact, the developers manage this documentation directly with markdown files located
+next to their code, so it is more convenient for them to keep it up-to-date. You can browse the ADRs
+by using the left menu or the search bar.
 
 The typical workflow of an ADR is the following:
 

docs/architectural-decisions/template.md

@@ -1,15 +1,18 @@
 # [short title of solved problem and solution]
 
-- Status: [draft | proposed | rejected | accepted | deprecated | … | superseded by [xxx](yyyymmdd-xxx.md)] <!-- optional -->
+- Status: [draft | proposed | rejected | accepted | deprecated | … | superseded by
+  [xxx](yyyymmdd-xxx.md)] <!-- optional -->
 - Deciders: [list everyone involved in the decision] <!-- optional -->
-- Date: [YYYY-MM-DD when the decision was last updated] <!-- optional. To customize the ordering without relying on Git creation dates and filenames -->
+- Date: [YYYY-MM-DD when the decision was last updated]
+  <!-- optional. To customize the ordering without relying on Git creation dates and filenames -->
 - Tags: [space and/or comma separated list of tags] <!-- optional -->
 
 Technical Story: [description | ticket/issue URL] <!-- optional -->
 
 ## Context and Problem Statement
 
-[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
+[Describe the context and problem statement, e.g., in free form using two to three sentences. You
+may want to articulate the problem in form of a question.]
 
 ## Decision Drivers <!-- optional -->
 
@@ -26,7 +29,8 @@ Technical Story: [description | ticket/issue URL] <!-- optional -->
 
 ## Decision Outcome
 
-Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion
+decision driver | which resolves force force | … | comes out best (see below)].
 
 ### Positive Consequences <!-- optional -->
 

docs/data-tracking-plan.md

@@ -74,8 +74,8 @@ important business decisions.
 > [naming convention](https://segment.com/academy/collecting-data/naming-conventions-for-clean-data/)
 > is critical to consistent accurate analytics.
 
-We follow Segment's
-recommended [object-action framework](https://segment.com/academy/collecting-data/naming-conventions-for-clean-data/)
+We follow Segment's recommended
+[object-action framework](https://segment.com/academy/collecting-data/naming-conventions-for-clean-data/)
 naming convention.
 
 This naming convention is simple, easy to implement, extensible, and most importantly, Segment will

docs/pull-request-guidelines.md

@@ -102,17 +102,16 @@ follow along, and enables to look-up decisions and understand code development a
 
 ### Don't Add to the PR Yourself
 
-It's sometimes tempting to fix a bug in a PR yourself, to rework a section to meet coding
-standards, or to merge the PR yourself.
+It's sometimes tempting to fix a bug in a PR yourself, to rework a section to meet coding standards,
+or to merge the PR yourself.
 
 If you do this without communicating beforehand with the author, you might interfere with his work
 and steal the opportunity to explain what he did. For code changes, use instead
 [GitHub suggestions](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request)
 to propose code changes that the author can easily commit.
 
-If the original PR is “good enough,” approve the PR and leave comments about the changes
-you'd like to see. If the author doesn't have time to make the changes, you can make them yourself
-in a new PR.
+If the original PR is “good enough,” approve the PR and leave comments about the changes you'd like
+to see. If the author doesn't have time to make the changes, you can make them yourself in a new PR.
 
 Regarding the merge, the author is always the best person to know when the PR is ready to be merged,
 especially when there are dependencies like other PRs that need to be merged first, configuration

lint-staged.config.mjs

@@ -4,6 +4,8 @@ const ESLintTask = (fileNames) =>
     .join(' --file ')}`;
 
 export default {
+  // Type-check TypeScript files
+  '**/*.{ts,tsx}': () => 'tsc -p tsconfig.json --noEmit',
   // Run tests
   './src/**/*.{ts,tsx}': 'jest --bail --passWithNoTests --findRelatedTests',
   // Run ESLint and Prettier consecutively so that the tasks don't conflict with each other

next.config.js

@@ -32,7 +32,7 @@ const nextConfig = {
         issuer: fileLoaderRule.issuer,
         resourceQuery: { not: [...fileLoaderRule.resourceQuery.not, /url/] }, // exclude if *.svg?url
         use: ['@svgr/webpack'],
-      }
+      },
     );
 
     // Modify the file loader rule to ignore *.svg, since we have it handled now.
@@ -43,7 +43,7 @@ const nextConfig = {
     config.plugins.push(
       new webpack.DefinePlugin({
         __SENTRY_DEBUG__: dev,
-      })
+      }),
     );
 
     return config;