createTransport()/sendMail() callback API unchanged between majors - smoke
tested the transport directly (confirmed correct error type, not an API
shape error) since the test suite doesn't exercise the email-sending path
(EMAIL_VERIFICATION off in tests). Full build + 179-test suite still pass.
3 unique vulnerable packages remain (aws-sdk's own advisory + its nested
uuid, vite/esbuild dev-server issue needing a major v5->v8 bump) - left
deliberately, all lower practical risk or need a dedicated upgrade pass.
- Removed @types/request (unused devDependency, no "request" import anywhere
in the codebase) - it was the actual source of the critical form-data
vulnerability via its own outdated nested dependency.
- Bumped uuid v3 -> v11 (patched version) across all 8 call sites, migrating
from the old default-import "uuid.v4()"/"uuid()" style to the named-export
"v4 as uuidv4" style the new major requires. Tried v14 first - it broke the
Jest test suite entirely (ships ESM-only, Node's CJS require() choked on
it) - v11 is the oldest patched version that still works under Jest/CJS.
Removed 2 more unused "import uuid" lines with no actual usage.
- Picked up brace-expansion via a follow-up non-breaking npm audit fix.
Verified full build (frontend+backend) and full test suite (179 tests)
after each step. 45 -> 4 unique vulnerable packages remaining: aws-sdk
(its own advisory, "fix" would downgrade it - not worth it), aws-sdk's
own nested uuid (same reason), esbuild/vite (major version bump to vite 8,
needs its own dedicated upgrade pass), and nodemailer (breaking API change,
only exercised when EMAIL_VERIFICATION is enabled) - all left for a
deliberate separate decision rather than forced through here.
Non-breaking transitive dependency bumps only (npm audit fix, no --force).
Verified build (frontend+backend) and full test suite (179 tests) still pass.
Remaining 7 (vite/esbuild, form-data, nodemailer, uuid) all require
--force major version bumps that could break existing code - left for a
deliberate separate decision rather than bundled in here.
Two whole categories of colored elements had no dark: variant at all,
so they rendered as glaring white boxes or invisible near-black text
against the dark background:
- Native <input>/<select> elements with no explicit bg-* class at all
(just relied on the browser's default white background) - search bar,
login/reset password fields, share/download link fields, mover search,
change-password fields. The first class-sweep only added dark: variants
next to *existing* color classes, so these were invisible to it.
- Hardcoded hex colors (text-[#212b36], text-[#637381], text-[#919eab],
bg-[#f6f5fd], bg-[#ebe9f9], bg-[#F4F4F6]) used as arbitrary Tailwind
values across headings, file list details, and the login/reset pages -
same blind spot, since the sweep only searched for known class names.
Mapped each to the same dark palette already used elsewhere (gray-900/800/700
surfaces, gray-100/300/400 text) for consistency.
Was gitignored, so npm install (including inside the Docker build) floated
to whatever versions were latest at install time - which is exactly what
caused the moveMultipleFiles build failure last commit. Locking versions
so CI/Docker/local all resolve the same dependency tree.
{ new: true } only applies to findOneAndUpdate, not updateMany - it was
always a silent no-op here. Harmless until a stricter mongoose/mongodb
type resolution (no lockfile is committed, so installs float) rejected
it outright, breaking `npm run build` inside the Docker image.
Mongo services in both compose files are now commented out (with instructions
to re-enable) since DB_ENGINE now defaults to sqlite - no separate database
container required out of the box. db-data volume is mounted into the app
service (not just mongo) so it can hold the SQLite file too.
Also fixes a require-order bug in tests/utils/express-app.js: routers were
required (eagerly instantiating DB singletons via dbFactory) before the test
env file was loaded, so DB_ENGINE from .env.test was silently never applied -
it only worked before because the old hardcoded default happened to be mongo.
Dark mode: CSS custom properties + .dark class toggled via Redux/localStorage,
with a theme toggle in the Header and Settings page. Foundation didn't exist
yet despite prior assumption, so it was built from scratch.
SQLite: new DB_ENGINE=mongo|sqlite env var selects the metadata backend at
runtime (Mongo stays default, no behavior change unless opted in). File/thumbnail
bytes continue to use the existing fs/S3 storage path. Implemented via a shared
DB interface (dbTypes.ts) with parallel mongoDB/ and sqliteDB/ implementations,
selected through dbFactory.ts, with JWT/encryption logic extracted into
userCrypto.ts so both engines share it.
* feat(docker): add MongoDB and improve setup instructions
* fix: reduce docker image size and other minor improvements
* fix: reduce docker image size and other minor improvements
* docs: update README for correct env file naming
* feat(docker): add environment variables and enhance Docker instructions
* docs: update README structure and enhance installation instructions
* docs: update README to clarify requirements for Docker and non-Docker setups
* docs: update README to improve Docker instructions and formatting
* docs: update code blocks in README to use shell syntax highlighting
* docs: refine installation steps and environment variable instructions
* docs: enhance README formatting for Docker instructions
* docs: correct formatting for environment variable examples in README
* docs: enhance README with badges and improved formatting
* docs: improve Docker instructions and formatting in README
* docs: update README to use figure elements for image captions
* docs: update README to replace figure elements with markdown images
* docs: update README to use shell syntax highlighting for code blocks
* docs: fix typo in README for environment file renaming step
oxmc
Konrad Gadzina
subnub
subnub
Ayush Sehrawat
github-actions[bot]