Update dependencies

[arkid15r]

Proposed change

Run make update + manual updates

Checklist

• Required: I followed the contributing workflow
• Required: I verified that my code works as intended and resolves the issue as described
• Required: I ran make check-test locally: all warnings addressed, tests passed
• I used AI for code, documentation, tests, or communication related to this PR

[coderabbitai]

Summary by CodeRabbit

• Chores
  • Updated development and testing dependencies across the project, including pre-commit hooks, spell-checking tools, Playwright test framework, and npm packages
  • Restructured project configuration files for improved maintainability
  • Enhanced build process logging for better visibility during installation

Walkthrough

Refactors Poetry/pyproject structure in backend and docs, bumps several dependency and image versions, updates a pre-commit hook, and adds --verbose to Poetry installs in multiple Dockerfiles. No public API signatures changed.

Changes

Cohort / File(s)	Summary
Pre-commit & linting dict \.pre-commit-config.yaml, cspell/package.json	Bumped pyproject-fmt pre-commit rev v2.12.1 → v2.14.2 and @cspell/dict-en_us ^4.4.28 → ^4.4.29.
Backend pyproject refactor backend/pyproject.toml	Reorganized Poetry and tool sections to use prefixed hierarchical keys (e.g., dependencies.*, group.*.*); migrated pytest/coverage/ruff config keys to new structure. Large structural change to TOML layout.
Docs pyproject alignment docs/pyproject.toml	Switched dependency declarations to dependencies.* prefixed keys to match new layout used elsewhere.
Dockerfiles — Poetry verbose flag docker/backend/Dockerfile, docker/backend/Dockerfile.local, docker/backend/Dockerfile.test, docker/backend/Dockerfile.video, docker/docs/Dockerfile.local	Added --verbose to poetry install invocations; no other behavior changes.
Frontend package updates frontend/package.json	Bumped framer-motion ^12.33.0 → ^12.34.0, posthog-js ^1.342.1 → ^1.343.2, @types/node ^25.2.1 → ^25.2.2 (deps and devDeps), and eslint-plugin-jest ^29.12.2 → ^29.13.0.
Frontend e2e base image docker/frontend/Dockerfile.e2e.test	Bumped Playwright base image v1.58.1 → v1.58.2 (jammy).

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Update dependencies' directly matches the PR's main objective of bumping multiple project dependencies across various files.
Description check	✅ Passed	The description is related to the changeset, describing the use of 'make update' and manual updates to bump dependencies, which aligns with the actual dependency version changes throughout the PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch ark/update-dependencies-2026-02-09

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

backend/pyproject.toml (1)

49-49: pyparsing is out of alphabetical order.

The main dependencies block (lines 12–48) is alphabetically sorted, but pyparsing at line 49 breaks that ordering — it should appear before pydantic (line 35).

Suggested reordering

Move dependencies.pyparsing = "^3.2.3" to appear between the psycopg2-binary and pydantic entries (around line 35).

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cubic-dev-ai]

No issues found across 15 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@backend/pyproject.toml`:
- Line 14: The pyproject.toml lists django-ninja==1.4.3 and
django-configurations==2.5.1 which are not declared compatible with Django 6.0;
update the dependency entries (the django-ninja and django-configurations lines
in pyproject.toml) to versions that support Django 6.0 (e.g., bump django-ninja
to 1.5.x or later and choose a django-configurations release that declares
Django 6 compatibility), then run the test suite against Django 6.0 to verify
compatibility and adjust versions if tests fail.

In `@docs/pyproject.toml`:
- Around line 11-16: The TOML uses dotted-key assignments like
dependencies.mkdocs and dependencies.python under [tool.poetry]; replace those
dotted-key lines by adding a [tool.poetry.dependencies] section header and move
the keys (mkdocs, mkdocs-material, mkdocs-minify-plugin, mkdocstrings,
pymdown-extensions, python) as regular keys under that section (e.g., mkdocs =
"...") to conform to Poetry 2.x standard and avoid dotted-key usage.

🧹 Nitpick comments (1)

backend/pyproject.toml (1)

12-60: pyparsing at line 49 breaks the alphabetical ordering of dependencies.

All other main dependencies (lines 12–48) are sorted alphabetically, but pyparsing is appended at the end after thefuzz. It should be placed between pydantic-core and pygithub to maintain consistency.

🔤 Move `pyparsing` to its alphabetical position

 dependencies.pydantic-core = "^2.33.0"
+dependencies.pyparsing = "^3.2.3"
 dependencies.pygithub = "^2.5.0"
...
 dependencies.thefuzz = "^0.22.1"
-dependencies.pyparsing = "^3.2.3"

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

Django 6.0 release date 2025 2026

💡 Result:

Django 6.0 was officially released on December 3, 2025. [1][2]

(For context: 6.0.1 shipped January 6, 2026 [3] and 6.0.2 shipped February 3, 2026 [4][5].)

Sources: [1] [2] [3] [4] [5]

---

🏁 Script executed:

# Read the full pyproject.toml to see actual dependencies
cat -n backend/pyproject.toml

Repository: OWASP/Nest

Length of output: 8446

---

🌐 Web query:

django-ninja 1.4.3 Django 6.0 compatibility

💡 Result:

django-ninja==1.4.3 is not marked as compatible with Django 6.0. On PyPI, its classifiers list Django support only up to Django 5.1 (no Django :: 6.0 classifier) and it was released Jun 4, 2025. [1]

If you need Django 6.0, use a newer django-ninja release: the current PyPI project metadata includes a Django :: 6.0 classifier (e.g., the 1.5.x line). [2]

Also note Django 6.0 requires Python 3.12+. [3]

Sources
[1] PyPI – django-ninja 1.4.3: (pypi.org)
[2] PyPI – django-ninja (latest): (pypi.org)
[3] Django 6.0 release notes (Python compatibility): (docs.djangoproject.com)

Citations:

• 1: https://pypi.org/project/django-ninja/1.4.3/
• 2: https://pypi.org/project/django-ninja/?utm_source=openai
• 3: https://docs.djangoproject.com/en/dev/releases/6.0/?utm_source=openai

---

🌐 Web query:

strawberry-graphql-django 0.75.0 Django 6.0 support

💡 Result:

strawberry-graphql-django 0.75.0 (released Jan 27, 2026) explicitly declares Django 6.0 support via its PyPI framework classifiers (Framework :: Django :: 6.0). It also requires Python >= 3.10. [1]

Sources:
[1] PyPI project page for strawberry-graphql-django 0.75.0 (classifiers + release date) (pypi.org)

Citations:

• 1: https://pypi.org/project/strawberry-graphql-django/

---

🌐 Web query:

django-configurations 2.5.1 Django 6.0 compatibility

💡 Result:

django-configurations 2.5.1 does not claim Django 6.0 compatibility. Its PyPI classifiers list support for Django 3.2, 4.1, 4.2, and 5.0 (and Python >=3.8,<4.0)—no Django 6.0 classifier is present. [1]

Since Django 6.0 requires Python 3.12+ and includes breaking/deprecation-driven changes, you should assume django-configurations 2.5.1 is “unverified/unsupported on Django 6.0” unless you run its test suite (or your project’s tests) against Django 6.0 and it passes. [2]

Sources: [1] [2]

---

Upgrade django-ninja and django-configurations for Django 6.0 compatibility.

django-ninja==1.4.3 does not support Django 6.0 (only Django ≤5.1). Upgrade to version 1.5.x or later.

django-configurations==2.5.1 lacks Django 6.0 support declarations on PyPI (classifiers only cover up to Django 5.0). Verify compatibility by running the test suite against Django 6.0, or upgrade to a version that explicitly supports Django 6.0.

All other listed dependencies (django-redis, django-rq, django-storages, strawberry-graphql-django, sentry-sdk) are compatible with Django 6.0.

🤖 Prompt for AI Agents

In `@backend/pyproject.toml` at line 14, The pyproject.toml lists
django-ninja==1.4.3 and django-configurations==2.5.1 which are not declared
compatible with Django 6.0; update the dependency entries (the django-ninja and
django-configurations lines in pyproject.toml) to versions that support Django
6.0 (e.g., bump django-ninja to 1.5.x or later and choose a
django-configurations release that declares Django 6 compatibility), then run
the test suite against Django 6.0 to verify compatibility and adjust versions if
tests fail.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

find . -name "pyproject.toml" -path "*/docs/*" | head -20

Repository: OWASP/Nest

Length of output: 75

---

🌐 Web query:

Poetry 2.x pyproject.toml dependencies format dotted keys

💡 Result:

In Poetry 2.x you have two good options when a dependency name contains a dot (e.g. zope.interface), because in TOML an unquoted a.b key is a dotted key (it creates nested tables) rather than a literal key name. Use a quoted key if you’re in a TOML table, or switch to PEP 621 string dependencies.

Option A (recommended in Poetry 2.x): PEP 621 strings (no TOML key issues)

[project]
dependencies = [
  "zope.interface>=6,<7",
]

Poetry 2.x supports specifying main dependencies in project.dependencies as PEP 508 strings. [1]

Option B (legacy / still supported): quote the key under tool.poetry.dependencies

[tool.poetry.dependencies]
"zope.interface" = "^6.0"

TOML allows quoted keys (so the dot is part of the key name), whereas bare keys can’t contain dots. [2] Real-world Poetry projects use this quoting pattern for dotted package names. [3]

Sources:
[1] Poetry docs – Dependency specification (project.dependencies vs tool.poetry.dependencies) (python-poetry.org)
[2] TOML spec – keys, quoted keys, and dotted keys (toml.io)
[3] Example pyproject.toml showing "zope.interface" in [tool.poetry.dependencies] (sources.debian.org)

Citations:

• 1: https://python-poetry.org/docs/dependency-specification/
• 2: https://toml.io/en/v1.1.0?utm_source=openai
• 3: https://sources.debian.org/src/python-pysaml2/7.5.0-7/pyproject.toml?utm_source=openai

---

🏁 Script executed:

cat -n ./docs/pyproject.toml | head -30

Repository: OWASP/Nest

Length of output: 666

---

🌐 Web query:

Poetry 2.0 tool.poetry dependencies dotted key format support

💡 Result:

Poetry 2.x doesn’t implement any special “dotted-key dependency syntax” of its own; it just reads whatever your TOML parser produces.

• If by “dotted key format” you mean TOML dotted keys like tool.poetry.dependencies.requests = "^2.31": that’s standard TOML dotted-key notation (it creates nested tables) and can represent the same data structure Poetry expects. (toml.io)
• However, standard TOML forbids mixing a [tool.poetry.dependencies] table header with dotted keys that (re)define that same table path, which makes such files error-prone across TOML parsers/tools. (toml.io)
• In Poetry 2.x, the recommended modern/standard place for dependencies is [project].dependencies (PEP 508 strings); [tool.poetry.dependencies] remains Poetry’s extended table format. (deepwiki.com)

So: there’s no Poetry-2.0-specific “support switch”—it’s mainly a TOML validity/compatibility question. For best compatibility, stick to [tool.poetry.dependencies] entries (table form) or move to [project].dependencies rather than relying on dotted-key assignments. (deepwiki.com)

Citations:

• 1: https://toml.io/en/v1.0.0?utm_source=openai
• 2: https://toml.io/en/v1.0.0?utm_source=openai
• 3: https://deepwiki.com/python-poetry/poetry/3.2-dependency-specification?utm_source=openai
• 4: https://deepwiki.com/python-poetry/poetry/3.2-dependency-specification?utm_source=openai

---

🏁 Script executed:

wc -l ./docs/pyproject.toml && cat ./docs/pyproject.toml

Repository: OWASP/Nest

Length of output: 579

---

Use [tool.poetry.dependencies] section header instead of dotted-key format.

The dotted-key syntax (dependencies.mkdocs = "^1.6.1") under [tool.poetry] is valid TOML but not the recommended Poetry 2.x format. Per Poetry documentation, use the standard section header format:

[tool.poetry.dependencies]
mkdocs = "^1.6.1"
mkdocs-material = "^9.6.19"
mkdocs-minify-plugin = "^0.8.0"
mkdocstrings = "^1.0.0"
pymdown-extensions = "^10.20.0"
python = "^3.13"

Dotted-key assignments for this purpose are error-prone across TOML parsers and deviate from Poetry's standard conventions.

🤖 Prompt for AI Agents

In `@docs/pyproject.toml` around lines 11 - 16, The TOML uses dotted-key
assignments like dependencies.mkdocs and dependencies.python under
[tool.poetry]; replace those dotted-key lines by adding a
[tool.poetry.dependencies] section header and move the keys (mkdocs,
mkdocs-material, mkdocs-minify-plugin, mkdocstrings, pymdown-extensions, python)
as regular keys under that section (e.g., mkdocs = "...") to conform to Poetry
2.x standard and avoid dotted-key usage.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.13%. Comparing base (8b5c58c) to head (a2b82b6).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3874   +/-   ##
=======================================
  Coverage   93.13%   93.13%           
=======================================
  Files         463      463           
  Lines       14531    14531           
  Branches     2061     2061           
=======================================
  Hits        13533    13533           
  Misses        538      538           
  Partials      460      460           

Flag	Coverage Δ
backend	95.65% <ø> (ø)
frontend	86.28% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8b5c58c...a2b82b6. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sonarqubecloud]

❌ The last analysis has failed.

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

x