feat: show migrations directory path in database status

[eduardoboucas]

No description provided.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Database status output now exposes and displays the migrations directory path in both JSON and human-readable formats.

• Tests

  • Added unit tests verifying the migrations directory path appears in JSON and pretty outputs and respects configuration overrides.

Walkthrough

The database status command now surfaces the migrations directory path in its output. RenderParams gained a required migrationsDirectory field; renderPretty prints a "Migrations directory: " line, and JSON output includes a migrationsPath property. The directory value comes from the resolved configuration (default or overridden). Unit tests were added to assert the migrations path is present and correct in both JSON and human-readable outputs.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	No pull request description was provided by the author, making it impossible to assess whether the description relates to the changeset.	Add a description explaining the purpose and context of the changes, such as why showing the migrations directory is useful and how it improves the user experience.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: adding display of the migrations directory path to the database status command output.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

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

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/db-status-migrations-directory

---

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

[coderabbitai]

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 `@tests/unit/commands/database/db-status.test.ts`:
- Around line 363-369: The tests call statusDb with createMockCommand(), but
createMockCommand injects db.migrations.path by default so they never exercise
the fallback resolution; update the tests that assert migrationsPath (the ones
using statusDb, jsonMessages and createMockCommand) to call createMockCommand
without the configured db.migrations.path (e.g., pass a mock command override
that omits or sets db.migrations.path to undefined) so the code computes the
default/fallback path and the assertions validate that resolved fallback value
instead of the injected config.

🪄 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: 16325f0d-d26d-4dac-b923-172056822c8e

📥 Commits

Reviewing files that changed from the base of the PR and between cf93d1f and 74a5eba.

📒 Files selected for processing (2)

• src/commands/database/db-status.ts
• tests/unit/commands/database/db-status.test.ts

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Default-path tests are exercising configured-path behavior, not fallback resolution.

On Line 364 and Line 511, createMockCommand() injects db.migrations.path by default, so these tests don’t validate the no-config fallback path computation.

Suggested test fix

-    test('includes the resolved migrations directory in JSON output', async () => {
-      await statusDb({ json: true }, createMockCommand())
+    test('includes the resolved migrations directory in JSON output', async () => {
+      await statusDb({ json: true }, createMockCommand({ migrationsPath: null }))

       expect(jsonMessages[0]).toMatchObject({
         migrationsPath: '/project/netlify/database/migrations',
       })
     })

-    test('renders a dedicated line for the migrations directory', async () => {
-      await statusDb({}, createMockCommand())
+    test('renders a dedicated line for the migrations directory', async () => {
+      await statusDb({}, createMockCommand({ migrationsPath: null }))

       expect(logMessages.join('\n')).toContain('Migrations directory: /project/netlify/database/migrations')
     })

Also applies to: 510-514

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/unit/commands/database/db-status.test.ts` around lines 363 - 369, The
tests call statusDb with createMockCommand(), but createMockCommand injects
db.migrations.path by default so they never exercise the fallback resolution;
update the tests that assert migrationsPath (the ones using statusDb,
jsonMessages and createMockCommand) to call createMockCommand without the
configured db.migrations.path (e.g., pass a mock command override that omits or
sets db.migrations.path to undefined) so the code computes the default/fallback
path and the assertions validate that resolved fallback value instead of the
injected config.

[github-actions]

📊 Benchmark results

Comparing with 69f05af

• Dependency count: 1,061 (no change)
• Package size: 355 MB (no change)
• Number of ts-expect-error directives: 356 (no change)

[coderabbitai]

🧹 Nitpick comments (1)

src/commands/database/db-status.ts (1)

442-442: Consider renaming the JSON key for consistency.

Line 442 uses migrationsPath, while internal naming and UI use migrationsDirectory. Aligning on one term would reduce mental mapping for consumers.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/database/db-status.ts` at line 442, The JSON key currently uses
migrationsPath but the codebase and UI use migrationsDirectory; update the
object key from migrationsPath to migrationsDirectory (i.e., change the
assignment "migrationsPath: migrationsDirectory" to "migrationsDirectory:
migrationsDirectory") wherever that pattern appears (e.g., in the db-status
construction or export that emits this JSON) so naming is consistent with
internal identifiers and UI; if consumers expect the old key, consider adding a
short compatibility shim that writes both keys or documents the change.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/commands/database/db-status.ts`:
- Line 442: The JSON key currently uses migrationsPath but the codebase and UI
use migrationsDirectory; update the object key from migrationsPath to
migrationsDirectory (i.e., change the assignment "migrationsPath:
migrationsDirectory" to "migrationsDirectory: migrationsDirectory") wherever
that pattern appears (e.g., in the db-status construction or export that emits
this JSON) so naming is consistent with internal identifiers and UI; if
consumers expect the old key, consider adding a short compatibility shim that
writes both keys or documents the change.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 79be1091-27ad-45e8-89a8-be0dece92266

📥 Commits

Reviewing files that changed from the base of the PR and between 74a5eba and c8f917b.

📒 Files selected for processing (2)

• src/commands/database/db-status.ts
• tests/unit/commands/database/db-status.test.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• tests/unit/commands/database/db-status.test.ts