update prisma

.gitignore

@@ -9,6 +9,7 @@ node_modules
 /prisma/data.db
 /prisma/data.db-journal
 /tests/prisma
+/prisma/generated
 
 /test-results/
 /playwright-report/

app/routes/users/index.tsx

@@ -1,4 +1,4 @@
-import { searchUsers } from '@prisma/client/sql'
+import { searchUsers } from '#prisma/generated/sql.ts'
 import { Img } from 'openimg/react'
 import { redirect, Link } from 'react-router'
 import { GeneralErrorBoundary } from '#app/components/error-boundary.tsx'

app/utils/auth.server.ts

@@ -1,5 +1,9 @@
 import crypto from 'node:crypto'
-import { type Connection, type Password, type User } from '@prisma/client'
+import {
+	type Connection,
+	type Password,
+	type User,
+} from '#prisma/generated/client.ts'
 import bcrypt from 'bcryptjs'
 import { redirect } from 'react-router'
 import { Authenticator } from 'remix-auth'

app/utils/db.server.ts

@@ -1,7 +1,8 @@
+import 'dotenv/config'
 import { styleText } from 'node:util'
 import { remember } from '@epic-web/remember'
-// Changed import due to issue: https://github.com/remix-run/react-router/pull/12644
-import { PrismaClient } from '@prisma/client/index.js'
+import { PrismaClient } from '#prisma/generated/client.ts'
+import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3'
 
 export const prisma = remember('prisma', () => {
 	// NOTE: if you change anything in this function you'll need to restart
@@ -10,7 +11,9 @@
 	// Feel free to change this log threshold to something that makes sense for you
 	const logThreshold = 20
 
+	const adapter = new PrismaBetterSQLite3({ url: process.env.DATABASE_URL })
 	const client = new PrismaClient({
+		adapter,
 		log: [
 			{ level: 'query', emit: 'event' },
 			{ level: 'error', emit: 'stdout' },

docs/database.md

@@ -300,7 +300,6 @@ You've got a few options:
      re-generating the migration after fixing the error.
 3. If you do care about the data and don't have a backup, you can follow these
    steps:
-
    1. Comment out the
       [`exec` section from `litefs.yml` file](https://github.com/epicweb-dev/epic-stack/blob/main/other/litefs.yml#L31-L37).
 

docs/decisions/031-imports.md

@@ -28,9 +28,9 @@ and manually modify.
 Despite the magic of Path aliases, they are actually a standard `package.json`
 supported feature. Sort of.
 [The `"imports"` field](https://nodejs.org/api/packages.html#imports) in
-`package.json` allows you to configure aliases for your imports.
-TypeScript also uses this for its own Path aliases since version 5.4
-so you get autocomplete and type checking for your imports.
+`package.json` allows you to configure aliases for your imports. TypeScript also
+uses this for its own Path aliases since version 5.4 so you get autocomplete and
+type checking for your imports.
 
 By using the `"imports"` field, you don't have to do any special configuration
 for `vitest` or `eslint` to be able to resolve imports. They just resolve them
@@ -44,7 +44,8 @@ again it's just a matter of familiarity. So it's no big deal.
 
 ## Decision
 
-We're going to configure `"imports"` in the `package.json` to use path aliases for imports.
+We're going to configure `"imports"` in the `package.json` to use path aliases
+for imports.
 
 We'll set it to `"#*": "./*"` which will allow us to import anything in the root
 of the repo with `#<dirname>/<filepath>`.

docs/decisions/039-passkeys.md

@@ -11,7 +11,6 @@ username/password and OAuth providers. While these methods are widely used, they
 come with various security challenges:
 
 1. Password-based authentication:
-
    - Users often reuse passwords across services
    - Passwords can be phished or stolen
    - Password management is a burden for users
@@ -39,14 +38,12 @@ using:
 The authentication flow works as follows:
 
 1. Registration:
-
    - Server generates a challenge and sends registration options
    - Client creates a new key pair and signs the challenge with the private key
    - Public key and metadata are sent to the server for storage
    - Private key remains securely stored in the authenticator
 
 2. Authentication:
-
    - Server generates a new challenge
    - Client signs it with the stored private key
    - Server verifies the signature using the stored public key
@@ -64,19 +61,16 @@ While passkeys represent the future of authentication, we maintain support for
 password and OAuth authentication because:
 
 1. Adoption and Transition:
-
    - Passkey support is still rolling out across platforms and browsers
    - Users need time to become comfortable with the new technology
    - Organizations may have existing requirements for specific auth methods
 
 2. Fallback Options:
-
    - Some users may not have compatible devices
    - Enterprise environments might restrict biometric authentication
    - Backup authentication methods provide reliability
 
 3. User Choice:
-
    - Different users have different security/convenience preferences
    - Some scenarios may require specific authentication types
    - Supporting multiple methods maximizes accessibility
@@ -112,43 +106,37 @@ We chose SimpleWebAuthn because:
 ### Positive:
 
 1. Enhanced Security for Users:
-
    - Phishing-resistant authentication adds protection against common attacks
    - Hardware-backed security provides stronger guarantees than passwords alone
    - Biometric authentication reduces risk of credential sharing
 
 2. Improved User Experience Options:
-
    - Users can choose between password, OAuth, or passkey based on their needs
    - Native biometric flows provide fast and familiar authentication
    - Password manager integration enables seamless cross-device access
    - Multiple authentication methods increase accessibility
 
 3. Future-Proofing Authentication:
-
    - Adoption of web standard
    - Gradual transition path as passkey support grows
    - Meeting evolving security best practices
 
 ### Negative:
 
 1. Implementation Complexity:
-
    - WebAuthn is a complex specification
    - Need to handle various device capabilities
    - Must maintain backward compatibility
    - Need to maintain password-based auth as fallback
 
 2. User Education:
-
    - New technology requires user education
    - Some users may be hesitant to adopt
    - Need clear documentation and UI guidance
 
 ### Neutral:
 
 1. Data Storage:
-
    - New database model for passkeys
    - Additional storage requirements per user
    - Migration path for existing users

docs/decisions/043-pwnedpasswords.md

@@ -22,22 +22,19 @@ However, we wanted to implement this in a way that:
 We will integrate the HaveIBeenPwned Password API with the following approach:
 
 1. **Progressive Enhancement**
-
    - The password check is implemented as a non-blocking enhancement
    - If the check fails or times out (>1s), we allow the password
    - This ensures users can still set passwords even if the service is
      unavailable
 
 2. **Development Experience**
-
    - The API calls are mocked during development and testing using MSW (Mock
      Service Worker)
    - This prevents unnecessary API calls during development
    - Allows for consistent testing behavior
    - Follows our pattern of mocking external services
 
 3. **Error Handling**
-
    - Timeout after 1 second to prevent blocking users
    - Graceful fallback if the service is unavailable
    - Warning logs for monitoring service health

docs/decisions/044-rr-devtools.md

@@ -6,34 +6,33 @@ Status: accepted
 
 ## Context
 
-Epic Stack uses React Router for routing. React Router is a powerful 
-library, but it can be difficult to debug and visualize the routing 
-in your application. This is especially true when you have a complex
-routing structure with nested routes, dynamic routes, and you rely 
-on data functions like loaders and actions, which the Epic Stack does.
-
-It is also hard to know which routes are currently active 
-(which ones are rendered) and if any if the loaders are triggered
-when you expect them to be. This can lead to confusion and frustration
-and the use of console.log statements to debug the routing in your 
-application. 
-
-This is where the React Router DevTools come in. The React
-Router DevTools are a set of tools that do all of these things for you. 
-
-React Router has a set of DevTools that help debug and visualize the 
-routing in your application. The DevTools allow you to see the
-current route information, including the current location, the matched 
-routes, and the route hierarchy. This can be very helpful when debugging
-your applications. The DevTools also hook into your server-side by 
-wrapping loaders and actions, allowing you to get extensive
-information about the data being loaded and the actions being dispatched.
+Epic Stack uses React Router for routing. React Router is a powerful library,
+but it can be difficult to debug and visualize the routing in your application.
+This is especially true when you have a complex routing structure with nested
+routes, dynamic routes, and you rely on data functions like loaders and actions,
+which the Epic Stack does.
+
+It is also hard to know which routes are currently active (which ones are
+rendered) and if any if the loaders are triggered when you expect them to be.
+This can lead to confusion and frustration and the use of console.log statements
+to debug the routing in your application.
+
+This is where the React Router DevTools come in. The React Router DevTools are a
+set of tools that do all of these things for you.
+
+React Router has a set of DevTools that help debug and visualize the routing in
+your application. The DevTools allow you to see the current route information,
+including the current location, the matched routes, and the route hierarchy.
+This can be very helpful when debugging your applications. The DevTools also
+hook into your server-side by wrapping loaders and actions, allowing you to get
+extensive information about the data being loaded and the actions being
+dispatched.
 
 ## Decision
 
-We will add the React Router DevTools to the Epic Stack. The DevTools 
-will be added to the project as a development dependency. The DevTools 
-will be used in development mode only. 
+We will add the React Router DevTools to the Epic Stack. The DevTools will be
+added to the project as a development dependency. The DevTools will be used in
+development mode only.
 
 The DevTools will be used to enhance the following:
 
@@ -45,19 +44,18 @@ The DevTools will be used to enhance the following:
 6. See cache information returned via headers from your loaders
 7. See which loaders/actions are triggered when you navigate to a route
 8. and a lot more!
-
 
 ## Consequences
 
 With the addition of the React Router DevTools, you will not have to rely on
-console.log statements to debug your routing. The DevTools will provide you 
-with the tools to ship your applications faster and with more confidence. 
+console.log statements to debug your routing. The DevTools will provide you with
+the tools to ship your applications faster and with more confidence.
 
-The DevTools will also help you visualize the routing in your application,
-which can be very helpful in understanding routing in general, and figuring
-out if your routes are set up correctly.
+The DevTools will also help you visualize the routing in your application, which
+can be very helpful in understanding routing in general, and figuring out if
+your routes are set up correctly.
 
-They are not included in the production build by default, so you will not
-have to worry about them being included in your production bundle. 
-They are only included in development mode, so you can use them without
-any negative performance impact in production.
+They are not included in the production build by default, so you will not have
+to worry about them being included in your production bundle. They are only
+included in development mode, so you can use them without any negative
+performance impact in production.