Update most dependencies (#1081)

Co-authored-by: me <me@kentcdodds.com>
Co-authored-by: Cursor Agent <cursoragent@cursor.com>

Author: kentcdodds

app/routes/_auth/auth.$provider/callback.test.ts

@@ -19,6 +19,11 @@ import { loader } from './callback.ts'
 
 const ROUTE_PATH = '/auth/github/callback'
 const PARAMS = { provider: 'github' }
+const LOADER_ARGS_BASE = {
+	params: PARAMS,
+	context: {} as AppLoadContext,
+	unstable_pattern: ROUTE_PATH,
+}
 
 afterEach(async () => {
 	await deleteGitHubUsers()
@@ -28,8 +33,7 @@ test('a new user goes to onboarding', async () => {
 	const request = await setupRequest()
 	const response = await loader({
 		request,
-		params: PARAMS,
-		context: {} as AppLoadContext,
+		...LOADER_ARGS_BASE,
 	}).catch((e) => e)
 	expect(response).toHaveRedirect('/onboarding/github')
 })
@@ -44,8 +48,7 @@ test('when auth fails, send the user to login with a toast', async () => {
 	const request = await setupRequest()
 	const response = await loader({
 		request,
-		params: PARAMS,
-		context: {} as AppLoadContext,
+		...LOADER_ARGS_BASE,
 	}).catch((e) => e)
 	invariant(response instanceof Response, 'response should be a Response')
 	expect(response).toHaveRedirect('/login')
@@ -67,8 +70,7 @@ test('when a user is logged in, it creates the connection', async () => {
 	})
 	const response = await loader({
 		request,
-		params: PARAMS,
-		context: {} as AppLoadContext,
+		...LOADER_ARGS_BASE,
 	})
 	expect(response).toHaveRedirect('/settings/profile/connections')
 	await expect(response).toSendToast(
@@ -107,8 +109,7 @@ test(`when a user is logged in and has already connected, it doesn't do anything
 	})
 	const response = await loader({
 		request,
-		params: PARAMS,
-		context: {} as AppLoadContext,
+		...LOADER_ARGS_BASE,
 	})
 	expect(response).toHaveRedirect('/settings/profile/connections')
 	await expect(response).toSendToast(
@@ -126,8 +127,7 @@ test('when a user exists with the same email, create connection and make session
 	const request = await setupRequest({ code: githubUser.code })
 	const response = await loader({
 		request,
-		params: PARAMS,
-		context: {} as AppLoadContext,
+		...LOADER_ARGS_BASE,
 	})
 
 	expect(response).toHaveRedirect('/')
@@ -174,8 +174,7 @@ test('gives an error if the account is already connected to another user', async
 	})
 	const response = await loader({
 		request,
-		params: PARAMS,
-		context: {} as AppLoadContext,
+		...LOADER_ARGS_BASE,
 	})
 	expect(response).toHaveRedirect('/settings/profile/connections')
 	await expect(response).toSendToast(
@@ -201,8 +200,7 @@ test('if a user is not logged in, but the connection exists, make a session', as
 	const request = await setupRequest({ code: githubUser.code })
 	const response = await loader({
 		request,
-		params: PARAMS,
-		context: {} as AppLoadContext,
+		...LOADER_ARGS_BASE,
 	})
 	expect(response).toHaveRedirect('/')
 	await expect(response).toHaveSessionForUser(userId)
@@ -229,8 +227,7 @@ test('if a user is not logged in, but the connection exists and they have enable
 	const request = await setupRequest({ code: githubUser.code })
 	const response = await loader({
 		request,
-		params: PARAMS,
-		context: {} as AppLoadContext,
+		...LOADER_ARGS_BASE,
 	})
 	const searchParams = new URLSearchParams({
 		type: twoFAVerificationType,

app/utils/cache.server.ts

@@ -24,10 +24,15 @@ const CACHE_DATABASE_PATH = process.env.CACHE_DATABASE_PATH
 const cacheDb = remember('cacheDb', createDatabase)
 
 function createDatabase(tryAgain = true): DatabaseSync {
-	const parentDir = path.dirname(CACHE_DATABASE_PATH)
+	const databasePath = CACHE_DATABASE_PATH
+	if (!databasePath) {
+		throw new Error('CACHE_DATABASE_PATH is not set')
+	}
+
+	const parentDir = path.dirname(databasePath)
 	fs.mkdirSync(parentDir, { recursive: true })
 
-	const db = new DatabaseSync(CACHE_DATABASE_PATH)
+	const db = new DatabaseSync(databasePath)
 	const { currentIsPrimary } = getInstanceInfoSync()
 	if (!currentIsPrimary) return db
 
@@ -41,10 +46,21 @@ function createDatabase(tryAgain = true): DatabaseSync {
 			)
 		`)
 	} catch (error: unknown) {
-		fs.unlinkSync(CACHE_DATABASE_PATH)
+		try {
+			fs.rmSync(databasePath, { force: true })
+		} catch (unlinkError) {
+			if (
+				typeof unlinkError !== 'object' ||
+				unlinkError === null ||
+				!('code' in unlinkError) ||
+				unlinkError.code !== 'ENOENT'
+			) {
+				throw unlinkError
+			}
+		}
 		if (tryAgain) {
 			console.error(
-				`Error creating cache database, deleting the file at "${CACHE_DATABASE_PATH}" and trying again...`,
+				`Error creating cache database, deleting the file at "${databasePath}" and trying again...`,
 			)
 			return createDatabase(false)
 		}

app/utils/storage.server.ts

@@ -14,7 +14,7 @@ async function uploadToStorage(file: File | FileUpload, key: string) {
 	const uploadResponse = await fetch(url, {
 		method: 'PUT',
 		headers,
-		body: file instanceof File ? file : file.stream(),
+		body: file instanceof File ? file : (file as FileUpload).stream(),
 	})
 
 	if (!uploadResponse.ok) {

docs/authentication.md

@@ -43,13 +43,12 @@ is a precondition for a "Mock GitHub server" to be installed (with the help of
 [module](../tests/mocks/github.ts) for more details and pay attention to how the
 calls to `https://github.com/login/oauth/access_token` are being intercepted.
 But once deployed to an environment where `process.env.MOCKS` is not set to
-`'true'` (see how this is done when launching the
-[server](../server/index.ts) and checked in the
-[entrypoint](../index.ts)), or even when developing _locally_ but not setting
-`GITHUB_CLIENT_ID` to `MOCK_...`, the requests will actually reach the GitHub
-auth server. This is where you will want to have a GitHub OAuth application
-properly set up, otherwise the logging in with GitHub will fail and a
-corresponding toast will appear on the screen.
+`'true'` (see how this is done when launching the [server](../server/index.ts)
+and checked in the [entrypoint](../index.ts)), or even when developing _locally_
+but not setting `GITHUB_CLIENT_ID` to `MOCK_...`, the requests will actually
+reach the GitHub auth server. This is where you will want to have a GitHub OAuth
+application properly set up, otherwise the logging in with GitHub will fail and
+a corresponding toast will appear on the screen.
 
 To set up a real OAuth application, log in to GitHub, go to
 `Settings -> Developer settings -> OAuth Apps`, and hit the

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.