Skip to content

Add unit tests for storage.controller.js#72

Merged
yash-pouranik merged 5 commits intogeturbackend:mainfrom
ayash911:feature/storage-tests
Apr 3, 2026
Merged

Add unit tests for storage.controller.js#72
yash-pouranik merged 5 commits intogeturbackend:mainfrom
ayash911:feature/storage-tests

Conversation

@ayash911
Copy link
Copy Markdown
Contributor

@ayash911 ayash911 commented Apr 2, 2026


🚀 Pull Request Description

Addresses the lack of test coverage for the public-api storage controller.

Added a comprehensive Jest test suite (apps/public-api/src/tests/storage.controller.test.js) covering:

  • uploadFile: Success, failures (invalid size, exceeding storage quotas), and internal vs external provider mocks.
  • deleteFile: Success, missing paths, unauthorized project access, and provider execution errors.
  • deleteAllFiles: Success via paginated deletion sweeps, and simulated retrieval failures.

Also added jest as a devDependency to the public-api workspace.

🛠️ Type of Change

  • 🐛 Bug fix (non-breaking change which fixes an issue)
  • ✨ New feature (non-breaking change which adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • 📝 Documentation update
  • 🎨 UI/UX improvement (Frontend only)
  • ⚙️ Refactor / Chore

🧪 Testing & Validation

Backend Verification:

  • I have run npm test in the backend/ directory and all tests passed (Verified with npx jest src/__tests__/storage.controller.test.js).
  • I have verified the API endpoints using Postman/Thunder Client.
  • New unit tests have been added (if applicable).

Frontend Verification:

  • I have run npm run lint in the frontend/ directory.
  • Verified the UI changes on different screen sizes (Responsive).
  • Checked for any console errors in the browser dev tools.

📸 Screenshots / Recordings (Optional)

Jest Test Output:

 PASS  src/__tests__/storage.controller.test.js
  storage.controller
    uploadFile
      ✓ returns 400 when no file is uploaded 
      ✓ returns 413 when file exceeds MAX_FILE_SIZE 
      ✓ returns 403 when internal storage quota is exceeded 
      ✓ returns 201 and public URL on successful internal upload 
      ✓ returns 201 and public URL on successful external upload (skips quota) 
      ✓ rolls back quota and returns 500 when upload fails 
    deleteFile
      ✓ returns 400 when file path is missing 
      ✓ returns 403 when trying to delete file belonging to different project 
      ✓ returns 200 on successful internal deletion 
      ✓ returns 200 on successful external deletion (skips internal usage list) 
      ✓ returns 500 when Supabase list fails 
      ✓ returns 500 when Supabase remove fails 
    deleteAllFiles
      ✓ returns 404 when project is not found 
      ✓ deletes paginated files and resets internal storage to 0 
      ✓ returns 500 if pagination fetch fails 

Test Suites: 1 passed, 1 total
Tests:       15 passed, 15 total

✅ Checklist

  • My code follows the code style of this project.
  • I have performed a self-review of my code.
  • I have commented my code, particularly in hard-to-understand areas.
  • My changes generate no new warnings or errors.
  • I have updated the documentation (README/Docs) accordingly.

Built with ❤️ for urBackend.

Summary by CodeRabbit

  • Bug Fixes

    • Improved file-deletion security with added path-sanitization to block traversal attempts and prevent unauthorized file access.
  • Tests

    • Added comprehensive tests for storage: uploads, single-file deletion, and batch deletion across internal and external providers, covering success flows, error handling, quota accounting, and rollback scenarios.

@vercel
Copy link
Copy Markdown

vercel bot commented Apr 2, 2026

@ayash911 is attempting to deploy a commit to the Yash Pouranik's projects Team on Vercel.

A member of the Team first needs to authorize it.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 2, 2026

📝 Walkthrough

Walkthrough

Adds a comprehensive Jest test suite for storage controller handlers, introduces a path-traversal check in deleteFile, and accidentally adds a duplicated devDependencies entry for Jest in apps/public-api/package.json.

Changes

Cohort / File(s) Summary
Storage Controller Tests
apps/public-api/src/__tests__/storage.controller.test.js
New ~350-line Jest test file covering uploadFile, deleteFile, deleteAllFiles. Mocks crypto.randomUUID, storage layer, and Project behaviors; verifies error paths, quota reservation/rollback, external vs internal provider flows, pagination, and failure cases.
Storage Controller
apps/public-api/src/controllers/storage.controller.js
Added path traversal check: deny deleteFile when requested path contains '..' segments in addition to existing project-prefix validation.
Package manifest
apps/public-api/package.json
Inserted an additional devDependencies block that pins jest to ^29.7.0, creating a duplicate devDependencies key alongside an existing (different) jest version.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related issues

Possibly related PRs

  • Feat/docs and branding #37: Modifies the same storage controller handlers (upload/delete) and quota logic; changes appear related at the code-level.

Suggested reviewers

  • KushagraJaiswar02

Poem

🐰
I hopped through tests with a careful pace,
Mocked UUIDs and storage in place.
I blocked sly paths that tried to sneak,
Counted bytes and rolled back when bleak.
A carrot-cheer for passing case! 🥕

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately and clearly summarizes the main change: adding unit tests for the storage controller, which is the primary focus of this changeset.
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

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

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

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a comprehensive test suite for the storage controller, covering file uploads, deletions, and bulk deletions for both internal and external storage. The feedback suggests enhancing the tests by adding cases for path traversal and removal failures, and refining assertions for the storage list method to verify that correct project IDs and search parameters are used.

Comment thread apps/public-api/src/__tests__/storage.controller.test.js
Comment thread apps/public-api/src/__tests__/storage.controller.test.js Outdated
Comment thread apps/public-api/src/__tests__/storage.controller.test.js
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
apps/public-api/src/__tests__/storage.controller.test.js (1)

257-307: Consider adding tests for external storage and remove failure in deleteAllFiles.

The current test suite covers pagination and list failure, but two scenarios are untested:

  1. External storage behavior: Verify that Project.updateOne is not called when isProjectStorageExternal returns true (similar to the deleteFile external test).

  2. Remove failure during bulk deletion: The controller calls remove inside the pagination loop and throws on removeError. A test asserting a 500 response would improve robustness.

📋 Suggested test cases
+        test('returns 200 on external bulk deletion (skips storageUsed reset)', async () => {
+            isProjectStorageExternal.mockReturnValue(true);
+            mockStorageFrom.list
+                .mockResolvedValueOnce({ data: [{ name: 'file1.txt' }], error: null })
+                .mockResolvedValueOnce({ data: [], error: null });
+            mockStorageFrom.remove.mockResolvedValue({ data: [], error: null });
+
+            const req = { project: makeProject() };
+            const res = makeRes();
+
+            await storageController.deleteAllFiles(req, res);
+
+            expect(Project.updateOne).not.toHaveBeenCalled();
+            expect(res.json).toHaveBeenCalledWith(expect.objectContaining({ provider: 'external' }));
+        });
+
+        test('returns 500 when remove fails during bulk deletion', async () => {
+            isProjectStorageExternal.mockReturnValue(false);
+            mockStorageFrom.list.mockResolvedValue({ data: [{ name: 'file1.txt' }], error: null });
+            mockStorageFrom.remove.mockResolvedValue({ data: null, error: new Error('Remove failed') });
+
+            const req = { project: makeProject() };
+            const res = makeRes();
+
+            await storageController.deleteAllFiles(req, res);
+
+            expect(res.status).toHaveBeenCalledWith(500);
+        });
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@apps/public-api/src/__tests__/storage.controller.test.js` around lines 257 -
307, Add two tests for storageController.deleteAllFiles: (1) simulate
isProjectStorageExternal.mockReturnValue(true) and assert that Project.updateOne
is NOT called and the response indicates provider: 'external' (use
makeProject(), makeRes(), and mockStorageFrom.list/remove as needed); (2)
simulate a remove failure by having mockStorageFrom.list return items but
mockStorageFrom.remove.mockResolvedValue({ data: null, error: new Error('Remove
failed') }) and assert the controller responds with status 500 and an error JSON
(verify mockStorageFrom.remove is called with the expected paths and that
res.status/res.json reflect the failure).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@apps/public-api/src/__tests__/storage.controller.test.js`:
- Around line 257-307: Add two tests for storageController.deleteAllFiles: (1)
simulate isProjectStorageExternal.mockReturnValue(true) and assert that
Project.updateOne is NOT called and the response indicates provider: 'external'
(use makeProject(), makeRes(), and mockStorageFrom.list/remove as needed); (2)
simulate a remove failure by having mockStorageFrom.list return items but
mockStorageFrom.remove.mockResolvedValue({ data: null, error: new Error('Remove
failed') }) and assert the controller responds with status 500 and an error JSON
(verify mockStorageFrom.remove is called with the expected paths and that
res.status/res.json reflect the failure).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3e76247d-865c-4984-87aa-0bf52237b1af

📥 Commits

Reviewing files that changed from the base of the PR and between b1cde91 and 4933787.

📒 Files selected for processing (1)
  • apps/public-api/src/__tests__/storage.controller.test.js

@yash-pouranik
Copy link
Copy Markdown
Collaborator

@coderabbitai OK to merge?

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 2, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Read the test file
cat apps/public-api/src/__tests__/storage.controller.test.js

echo "---CONTROLLER---"
# Find and read the storage controller
fd storage.controller.js --type f | head -5

Length of output: 13931


🏁 Script executed:

#!/bin/bash
cat apps/public-api/src/controllers/storage.controller.js

echo "---PACKAGE JSON---"
fd package.json --search-path apps/public-api --max-depth 1 | xargs cat

echo "---OPEN PR REVIEW COMMENTS---"
gh pr view 72 --repo yash-pouranik/urBackend --json reviews,comments

Length of output: 26362


@yash-pouranik, the PR is in good shape overall. Here's a quick summary of the assessment:

✅ What looks good:

  • All three handlers (uploadFile, deleteFile, deleteAllFiles) have solid coverage — happy paths, quota enforcement, rollback on upload failure, path traversal protection, and provider branching (internal vs. external) are all tested.
  • Pre-merge checks (title, description, docstring coverage) all passed.
  • Gemini's earlier suggestions (path traversal test, remove-failure test for deleteAllFiles) have been addressed.
  • One of my two nitpick suggestions (remove failure in deleteAllFiles) is already covered by the test 'returns 500 when Supabase remove fails during deleteAllFiles'.

⚠️ Two minor items to be aware of before merging:

  1. Missing jest in devDependencies: The package.json for public-api has a jest config block and a test script, but jest is not listed in devDependencies. If it's installed at the monorepo root (workspace-level), this isn't a problem — but you may want to confirm this is intentional so CI doesn't break in isolated installs.

  2. Remaining nitpick (non-blocking): The test for deleteAllFiles with an external storage provider (verifying Project.updateOne is not called when isProjectStorageExternal returns true) is still missing. This is a low-priority gap — consider adding it in a follow-up if you'd like complete symmetry with the deleteFile external test.

If jest is confirmed available at the workspace root and you're comfortable with the one missing test being a follow-up, this is ready to merge. 🚀

@yash-pouranik
Copy link
Copy Markdown
Collaborator

@ayash911 solve this 2 things then I will review my self and then merge.

@yash-pouranik
Copy link
Copy Markdown
Collaborator

@CodeRabbit all done??

@yash-pouranik yash-pouranik self-requested a review April 2, 2026 18:50
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 2, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check devDependencies in public-api package.json
fd package.json --search-path apps/public-api --max-depth 1 | xargs cat

echo "---TEST FILE---"
# Check if deleteAllFiles external provider test exists
cat apps/public-api/src/__tests__/storage.controller.test.js

Length of output: 14628


@yash-pouranik, not yet — both items are still open on the current branch:

❌ Item 1 — jest missing from devDependencies
The package.json still has no jest entry under devDependencies:

// current state — jest is absent from devDependencies
{
  "scripts": { "test": "jest --testPathPatterns=src/" },
  "jest": { "testEnvironment": "node" },
  "dependencies": { ... }
  // no devDependencies block at all
}

@ayash911 needs to add it:

"devDependencies": {
  "jest": "^29.7.0"
}

❌ Item 2 — Missing deleteAllFiles external provider test
The deleteAllFiles describe block still has no test asserting that Project.updateOne is not called when isProjectStorageExternal returns true. Here's what needs to be added:

test('skips storageUsed reset for external provider during deleteAllFiles', async () => {
    isProjectStorageExternal.mockReturnValue(true);

    mockStorageFrom.list
        .mockResolvedValueOnce({ data: [{ name: 'file1.txt' }], error: null })
        .mockResolvedValueOnce({ data: [], error: null });

    mockStorageFrom.remove.mockResolvedValue({ data: [{}], error: null });

    const req = { project: makeProject() };
    const res = makeRes();

    await storageController.deleteAllFiles(req, res);

    expect(Project.updateOne).not.toHaveBeenCalled();
    expect(res.json).toHaveBeenCalledWith(expect.objectContaining({ provider: 'external' }));
});

Note: The path traversal test for deleteFile was a nice addition — good work on that one!

Once @ayash911 addresses both items above, the PR will be ready to merge. 🚀

@ayash911 ayash911 force-pushed the feature/storage-tests branch from 23d86b5 to 4dc7218 Compare April 2, 2026 18:50
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/public-api/src/__tests__/storage.controller.test.js`:
- Around line 267-331: Add a test that pins the external-storage branch by
mocking isProjectStorageExternal(project) to return true, then have
mockStorageFrom.list return some files and mockStorageFrom.remove resolve
successfully; call storageController.deleteAllFiles(req, res) and assert that
mockStorageFrom.remove was called with the external file paths,
Project.updateOne was NOT called, and the response JSON contains success:true,
deleted:<n>, provider:'external' to prevent regressions in the deleteAllFiles
external branch (referencing storageController.deleteAllFiles,
isProjectStorageExternal, mockStorageFrom.list, mockStorageFrom.remove, and
Project.updateOne).
- Around line 1-40: The test runner 'jest' invoked by the test script ("jest
--testPathPatterns=src/") is not declared as a dependency for the public-api
package, which breaks isolated installs and CI; fix by adding 'jest' (and any
needed types like '@types/jest' if using TS) to the public-api package.json
devDependencies so the test script can run, or alternatively update the
repository documentation and CI config to explicitly state that Jest must always
be provided from the monorepo root; update the package.json that contains the
test script and ensure package-lock/yarn.lock is updated and CI uses the
declared dependency.

In `@apps/public-api/src/controllers/storage.controller.js`:
- Around line 102-103: The delete handler currently blocks any path containing
'..' but uploadFile still allows filenames like report..csv (it only trims
whitespace from file.originalname), causing uploads to succeed but deletes to
403; either sanitize/validate in uploadFile by rejecting or normalizing
file.originalname when building filePath (ensure names containing '..' are
rejected or escaped) or make the delete-time check stricter by normalizing the
incoming path (e.g., path.normalize) and checking path segments for a literal
'..' segment or ensuring the normalized path starts with `${project._id}/`;
update references in the uploadFile logic (file.originalname and filePath) or
the delete validation (path, project._id) accordingly so allowed filenames like
report..csv that are not path-traversal are not rejected while true traversal is
blocked.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 615e7826-e612-4c9f-b54d-77793d7f24be

📥 Commits

Reviewing files that changed from the base of the PR and between 4933787 and 23d86b5.

📒 Files selected for processing (3)
  • apps/public-api/src/__tests__/storage.controller.test.js
  • apps/public-api/src/controllers/data.controller.js
  • apps/public-api/src/controllers/storage.controller.js

Comment thread apps/public-api/src/__tests__/storage.controller.test.js
Comment thread apps/public-api/src/__tests__/storage.controller.test.js
Comment thread apps/public-api/src/controllers/storage.controller.js Outdated
@yash-pouranik
Copy link
Copy Markdown
Collaborator

@ayash911 some more changes 🤏

- Add jest to devDependencies in public-api package.json
- Add test for deleteAllFiles external provider path skipping quota reset
- Narrow down path traversal check in deleteFile from path.includes to checking exact path segments
@yash-pouranik
Copy link
Copy Markdown
Collaborator

Finally OK to merge @coderabbitai ?

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 3, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check devDependencies in public-api package.json
fd package.json --search-path apps/public-api --max-depth 1 | xargs cat

echo "---TEST FILE (deleteAllFiles section)---"
grep -n "external\|updateOne\|isProjectStorageExternal\|deleteAllFiles" apps/public-api/src/__tests__/storage.controller.test.js

Length of output: 3790


@yash-pouranik, yes — both items are fully resolved

Item Status
jest added to devDependencies ("jest": "^29.7.0") ✅ Done
deleteAllFiles external provider test ('skips storageUsed reset for external provider during deleteAllFiles') asserting Project.updateOne not called ✅ Done (line 305–320)

The PR is ready to merge. 🚀

@yash-pouranik
Copy link
Copy Markdown
Collaborator

@ayash911 CI is failing? @coderabbitai

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 3, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check CI status for PR `#72`
gh pr checks 72 --repo yash-pouranik/urBackend

echo "---PR STATUS---"
gh pr view 72 --repo yash-pouranik/urBackend --json statusCheckRollup,headRefName,headRefOid

echo "---RECENT WORKFLOW RUNS---"
gh run list --repo yash-pouranik/urBackend --limit 10 --json databaseId,name,status,conclusion,headSha,event,displayTitle

Length of output: 5406


🏁 Script executed:

#!/bin/bash
echo "---dashboard-api-tests logs---"
gh run view 23939486270 --repo yash-pouranik/urBackend --job 69824956794 --log-failed

echo "---frontend-lint logs---"
gh run view 23939486270 --repo yash-pouranik/urBackend --job 69824956801 --log-failed

Length of output: 39983


@yash-pouranik Yes — the root cause is clear. Both dashboard-api-tests and frontend-lint fail at the Install Dependencies step with:

npm error `npm ci` can only install packages when your package.json and
package-lock.json or npm-shrinkwrap.json are in sync.
npm error Missing: jest@29.7.0 from lock file

When @ayash911 added jest to devDependencies in apps/public-api/package.json, they forgot to regenerate the package-lock.json. npm ci (used in CI) is strict — it refuses to run if the lock file doesn't match package.json.

Fix for @ayash911: Run npm install from the repo root (to update the monorepo lock file), then commit the updated package-lock.json:

# From the repo root
npm install
git add package-lock.json
git commit -m "chore: update package-lock.json after adding jest devDependency"
git push

Note: The frontend-lint job is failing for the exact same reason — the lock file is out of sync repo-wide, so regenerating it once at the root will fix both jobs simultaneously. The Vercel failure is a separate authorization issue and is unrelated to this PR.

@yash-pouranik
Copy link
Copy Markdown
Collaborator

@ayash911 follow what coderabbit says

  • Run npm install from the repo root (to update the monorepo lock file), then commit the updated package-lock.json:

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/public-api/package.json`:
- Around line 14-16: Remove the duplicated "devDependencies" block that contains
"jest": "^29.7.0" and keep only the existing "devDependencies" block that
currently contains "jest": "^30.3.0"; then update that remaining "jest" entry in
the kept devDependencies to the intended version "^29.7.0" so the file has a
single devDependencies object with "jest": "^29.7.0".
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c5313176-c653-4449-91c9-26f81b658a62

📥 Commits

Reviewing files that changed from the base of the PR and between 19124a2 and 8b41a74.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (1)
  • apps/public-api/package.json

Comment on lines +14 to +16
"devDependencies": {
"jest": "^29.7.0"
},
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify which Jest versions exist on npm

echo "=== Checking if jest@30.3.0 exists ==="
npm view jest@30.3.0 version 2>&1 || echo "Version 30.3.0 does not exist"

echo ""
echo "=== Latest Jest version ==="
npm view jest version

echo ""
echo "=== Available Jest 29.x versions ==="
npm view jest versions --json | jq '.[] | select(startswith("29"))' | tail -5

echo ""
echo "=== Available Jest 30.x versions (if any) ==="
npm view jest versions --json | jq '.[] | select(startswith("30"))' || echo "No 30.x versions found"

Repository: yash-pouranik/urBackend

Length of output: 647


Duplicate devDependencies blocks will use the wrong Jest version.

The file contains two devDependencies blocks:

  • Lines 14-16: "jest": "^29.7.0" (newly added)
  • Lines 36-38: "jest": "^30.3.0" (pre-existing)

JSON parsers use the last occurrence, so npm will resolve to jest@30.3.0 and ignore the intended ^29.7.0. This contradicts the PR objective.

Remove the first devDependencies block (lines 14-16) to keep only the second one, then update it to use the intended version:

   "jest": {
     "testEnvironment": "node"
   },
-  "devDependencies": {
-    "jest": "^29.7.0"
-  },
   "dependencies": {
     "@kiroo/sdk": "^0.1.2"
   },
   "devDependencies": {
-    "jest": "^30.3.0"
+    "jest": "^29.7.0"
   }
 }
🧰 Tools
🪛 Biome (2.4.9)

[error] 14-14: The key devDependencies was already declared.

(lint/suspicious/noDuplicateObjectKeys)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@apps/public-api/package.json` around lines 14 - 16, Remove the duplicated
"devDependencies" block that contains "jest": "^29.7.0" and keep only the
existing "devDependencies" block that currently contains "jest": "^30.3.0"; then
update that remaining "jest" entry in the kept devDependencies to the intended
version "^29.7.0" so the file has a single devDependencies object with "jest":
"^29.7.0".

@yash-pouranik yash-pouranik merged commit 2e7e948 into geturbackend:main Apr 3, 2026
5 of 6 checks passed
@yash-pouranik
Copy link
Copy Markdown
Collaborator

Finally Merged! @ayash911 , thank you for the PR and dont forget to star the REPO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants