@@ -1087,20 +1087,23 @@ sudo docker compose up -d next-app
### The ` .dockerignore` situation (known issue)
There are two ` .dockerignore` files:
There is one ` .dockerignore ` file at the repo root: `/ .dockerignore`. Docker always
reads the ` .dockerignore` from the root of the build context, which is set to ` ../`
(the repo root) in ` compose.yml` — so the root file is the only one that ever applies.
- ` /.dockerignore ` (root) — has ` .env ` commented out, meaning the ` .env` file IS
included in the Docker build context
- ` /docker/.dockerignore` — explicitly excludes ` .env`
The ` .env ` file is intentionally included in the build context ( the ` .env` lines are
commented out in ` /.dockerignore`). This is how ` SENTRY_AUTH_TOKEN` and ` NEXT_PUBLIC_*`
variables reach the Next.js build step inside the container.
The Docker build context is set to the repo root in ` compose.yml`. The root
` .dockerignore ` is the one that applies. Because ` .env ` is not excluded, it gets sent
to the builder and environment variables are available at build time. This is how
` SENTRY_AUTH_TOKEN` and other build-time vars reach the Next.js build step.
Do not un-comment those lines without understanding the full implications — removing
` .env ` from the build context would break Sentry source map uploads and
` NEXT_PUBLIC_*` variable baking into the client bundle.
This is a known imperfect approach but it works. Do not "fix" it without understanding
the full implications — removing ` .env` from the build context would break Sentry
source map uploads and ` NEXT_PUBLIC_*` variable baking into the client bundle.
**Note on ` docker/.env`:** This file is entirely separate and serves a different
purpose. It is read by Docker Compose itself (not the build) to interpolate the
` ${VARIABLE}` placeholders in ` compose.yml` — things like container names, network
names, and Convex origin URLs. It is not the same as the root ` /.env` and the two
are not interchangeable.
### Convex data persistence
@@ -1287,43 +1290,16 @@ native fix for this or if a custom update script is needed.
---
**2. Password validation mismatch** ⚠️ Medium priority
**2. Password validation mismatch** ✅ Fixed
` packages/backend/types/auth.ts ` exports ` PASSWORD_REGEX ` which requires special
characters. ` packages/backend/convex/custom/auth/providers/password.ts::validatePassword()`
does NOT check for special characters. These two are inconsistent. The frontend sign-in
form does enforce special characters via its own Zod schema, but the backend validation
is weaker than the type definition implies. Either align ` validatePassword()` to match
` PASSWORD_REGEX`, or update ` PASSWORD_REGEX` to not require special characters.
` validatePassword() ` in ` packages/backend/convex/custom/auth/providers/password.ts `
now fully matches ` PASSWORD_REGEX` in ` packages/backend/types/auth.ts`. Both enforce:
minimum 8 characters, maximum 100, no whitespace, at least one digit, one lowercase
letter, one uppercase letter, and at least one special character (` [\p{P}\p{S}]`).
---
**3. ` import type ` enforcement removed** ✅ Fixed
The ` @typescript -eslint/consistent-type-imports` and ` import/consistent-type-specifier-style`
rules that forced separate ` import type` statements have been removed from
` tools/eslint/base.ts`. Type imports can now be mixed inline or on separate lines —
whatever reads most naturally in context.
---
**4. ` const` arrow function lint rule added** ✅ Fixed
` eslint-plugin-prefer-arrow-functions` has been added to ` tools/eslint/base.ts` and the
` prefer-arrow-functions/prefer-arrow-functions` rule is now enforced as a warning. All
function declarations across the codebase have been auto-converted to ` const` arrow
function syntax.
---
**5. Turbo generator uses pnpm** ✅ Fixed in this session
` turbo/generators/config.ts` previously called ` pnpm i` and ` pnpm prettier`. This has
been fixed to use ` bun install` and ` bun prettier`.
---
**6. Root ` .dockerignore` includes ` .env` in build context** ℹ ️ Known, works intentionally
**3. Root ` .dockerignore ` includes ` .env ` in build context** ℹ ️ Known, works intentionally
The root ` .dockerignore` has ` .env` commented out, meaning the ` .env` file is sent to
the Docker build context. This is how build-time env vars (Sentry token, ` NEXT_PUBLIC_*`)
@@ -1331,9 +1307,12 @@ reach the Next.js build step. It's a known imperfect approach but fully function
A proper solution would use Docker build args (` ARG`) or multi-stage secrets, but this
requires careful restructuring to avoid breaking Sentry source map uploads.
The redundant ` docker/.dockerignore` has been deleted — it was never read by Docker
since the build context is always the repo root.
---
**7 . In-memory IP banning resets on restart** ℹ ️ Future enhancement
**4 . In-memory IP banning resets on restart** ℹ ️ Future enhancement
` src/lib/proxy/ban-sus-ips.ts` stores bans in a JavaScript ` Map`. Bans reset whenever
the Next.js server restarts (container restart, redeploy, etc.). A more robust solution
@@ -1342,7 +1321,7 @@ job) or to Redis.
---
**8 . ` apps/next/src/lib/metadata.ts` has hardcoded branding** ⚠️ Template concern
**5 . ` apps/next/src/lib/metadata.ts` has hardcoded branding** ⚠️ Template concern
When using this as a template for a new project, ` metadata.ts` must be updated:
the title template (` '%s | Convex Monorepo'`) and any other project-specific strings.
@@ -1350,7 +1329,7 @@ Same for `next.config.js` `images.remotePatterns` (currently `*.gbrown.org`).
---
**9 . No CI/CD** ℹ ️ Future enhancement
**6 . No CI/CD** ℹ ️ Future enhancement
There is no ` .github/workflows/` directory. All deployment is done manually via SSH.
A future enhancement would add GitHub Actions (or Gitea Actions, since this repo is
@@ -1358,7 +1337,7 @@ on Gitea) for automated lint and typecheck on pull requests.
---
**10 . Scripts organization** ℹ ️ Future exploration
**7 . Scripts organization** ℹ ️ Future exploration
Currently:
@@ -1372,14 +1351,14 @@ moving everything to `docker/scripts/`.
---
**11 . Expo ` eas.json` specifies pnpm** ⚠️ Low priority (Expo is WIP anyway)
**8 . Expo ` eas.json` specifies pnpm** ⚠️ Low priority (Expo is WIP anyway)
` apps/expo/eas.json` specifies ` pnpm 9.15.4` as the package manager. Should specify
bun. This is low priority since the Expo app is not in active development.
---
**12 . React Email templates not yet implemented** ℹ ️ Future enhancement
**9 . React Email templates not yet implemented** ℹ ️ Future enhancement
` @react -email/components` and ` react-email` are in ` packages/backend/package.json` as
planned dependencies. The current ` usesend.ts` uses inline HTML strings for email