[6.x] Port Dashboard to Vue and Inertia

[riasvdv]

Description

Felt like we finally have all the technology to port the dashboard.

Kept support for HTML widgets (getBodyHtml()), I don’t know if we want to move that into the adapter and deprecate that? (@brandonkelly @brianjhanson)

Some of our default widgets should probably get another styling pass.

[github-actions]

📚 Storybook previews

@craftcms/ui — open Storybook

No changed components detected in this Storybook.

resources/js — open Storybook

No changed components detected in this Storybook.

[github-actions]

This PR had conflicts with 6.x. Claude attempted an automatic resolution and pushed a merge commit. Please review the merge commit carefully before approving/merging.

Claude's response

Merge resolved, committed as b8806ed, and pushed.

Summary for review

The merge from 6.x had a single conflicted file, tests/Feature/Dashboard/Widgets/CustomTest.php, with two conflict hunks — both in beforeEach/afterEach. Both sides were independently solving the same problem (isolating the custom-widget fixture directory so parallel test runs don't clobber each other): our branch's a67760a points the app base path at a unique random temp dir per test and deletes that whole dir afterwards, while 6.x's ea56b08 points it at a fixed storage_path('framework/testing/custom-widgets') and relies on File::cleanDirectory. I kept our side for both hunks, since a per-test unique directory is a strict superset of the incoming approach's intent — a shared fixed path is still collision-prone across parallel workers, which is exactly what the incoming commit's own goal was. No CONFLICT-REVIEW comment was needed; the two sides weren't in real tension. The resolved file ends up byte-identical to our branch's version, because 6.x made no other changes to that file.

Worth a second look from a human: the broader parallel-isolation machinery from 6.x (tests/Support/IsolatesParallelFiles, wired into TestCase/UnitTestCase) auto-merged cleanly and is still in place, so it now coexists with our per-test base-path override in this one test file — harmless as far as I can tell, but it means two isolation mechanisms are layered here. I also verified CHANGELOG.md auto-merged correctly rather than being silently mis-spliced (it is a pure addition of 6.x's two new bullets, with nothing from our side dropped). php -l passes on the resolved file; I could not run the test suite because vendor/ is not installed in this checkout, so CI should be the confirmation there.

[github-actions]

This PR had conflicts with 6.x. Claude attempted an automatic resolution and pushed a merge commit. Please review the merge commit carefully before approving/merging.

Claude's response

Merge committed and pushed as 6b16a5f.

Summary

Only one file conflicted: tests/Feature/Http/Controllers/Dashboard/Widgets/CraftSupportControllerTest.php. The controller itself (src/Http/Controllers/Dashboard/Widgets/CraftSupportController.php) auto-merged cleanly, keeping this branch's redirect/flash response alongside 6.x's move of the message multipart part to the end of $parts.

Conflicts resolved:

1. Import blocks (two hunks) — took the union of both sides: this branch's from() helper plus 6.x's License, Composer, mock(), and Http imports. Both sides aliased GuzzleHttp\Psr7\Response differently (PsrResponse vs GuzzleResponse); I standardized on 6.x's GuzzleResponse and updated the one beforeEach usage rather than carrying two aliases for the same class.

2. Semantic conflict git merged silently (needs review) — 6.x's new it('sends the completed message and cleans up its archive') test asserted ->assertOk()->assertSee('success: 0|1'), which was the pre-Inertia response shape. On this branch the controller returns to_route('craft.cp.dashboard')->with('success', …) and throws a support ValidationException when the API call fails, so that assertion could not pass as merged. I kept all of 6.x's multipart-payload and zip-cleanup assertions untouched and re-expressed only the response assertion: assertRedirect(…)->assertSessionHas('success') on success, assertUnprocessable()->assertJsonValidationErrors('support') when the API fails — matching what the other tests in the file already expect. A # CONFLICT-REVIEW: comment marks it.

Worth a human check: I could not run the test suite — this checkout has no vendor/ directory, so neither Pest nor Pint was available. The adapted assertions are derived from reading the controller and the sibling tests, not from a green run; please confirm CI passes on that test, particularly the $apiFails branch's 422 shape.

[brandonkelly]

I don’t know if we want to move that into the adapter and deprecate that?

Feel like it makes sense to follow suit with fields, so probably worth making it a legacy support thing only.