feat: convert redirect page to inertia

[Chew]

Very basic for now. Doesn't change anything, but open to ideas for improvements.

Only notable change is instead of a <a href> it uses window.location.replace, which will make pressing "Back" on the browser go to the original page instead of this redirect page.

Also, of course, a test and i18n keys.

Redirect's route was moved into an Inertia middleware so it could work, it could be moved elsewhere if needed.

Preview, if relevant.

[wescopeland]

Will do an exhaustive review either later this evening or tomorrow once checks are passing, but wanted to shoot along one quick comment.

[wescopeland]

Looks like we've got a coverage gap in Vitest:

ERROR: Coverage for functions (99.91%) does not meet global threshold (100%)

PHPUnit is upset about the controller returning Inertia stuff rather than a Blade view. I wonder if HomeControllerTest might have a few ideas on how this could be resolved.

[Chew]

I'll take a look at that, I might have to update our inertiajs/inertia-laravel package to let us check props with inertiaProps() since that was added in 2.0.3 and we are on 2.0. I can try the where thing too, but I'm not sure what specifically to check for. Turns out this was unrelated, we should be good.

[wescopeland]

Still looks like we're having some trouble with the PHPUnit test suite: https://github.com/RetroAchievements/RAWeb/actions/runs/19050202919/job/54408281395?pr=4076

Want me to try to poke around?

[Chew]

Yeah I'm not sure where the issue is coming from. These tests run fine locally for me

[wescopeland]

They all pass for me too. I wonder if this might fix it, would you mind trying this solution?

// config/inertia.php

// line 50
            resource_path('js/pages'),

"Pages" -> "pages".
I'm wondering if it's a file system / sensitivity issue with CI specifically.

[Jamiras]

They all pass for me too. I wonder if this might fix it, would you mind trying this solution?

// config/inertia.php

// line 50
            resource_path('js/pages'),

"Pages" -> "pages". I'm wondering if it's a file system / sensitivity issue with CI specifically.

I do see the errors on my VM and this prescribed change does make them go away.

...F.....F.F.FF...F..F.......................................  671 / 1127 ( 59%)

.............................................................  671 / 1127 ( 59%)

[Chew]

I think it might be a case sensitivity issue since I use Mac and it does not have case sensitive folders like Linux (and presumably Windows).

[wescopeland]

I wonder if there's any way we can make this compatible both with raweb.test and localhost:64000. For a moment, I thought something was wrong with my local env 😅

[wescopeland]

Maybe in one or more git hooks we can auto-run composer types? Though I suppose this may also produce undesirable noise in commits later.

[Chew]

I'm not super familiar with this ziggy.js file, does it need to be committed at all? If we remove it, then ignore it, and keep an ignored file, what happens?

[wescopeland]

Good question. Every time I pull this branch, it breaks my local (and I'm sure you experience something similar for our branches).

The ziggy.js file is glue between the Inertia app and Laravel's strongly-typed routes. Without it, all routing in the Inertia app breaks.

Our deployment script automatically rebuilds the file on every deploy. I wonder if it would indeed be best to gitignore it and automatically execute php artisan ziggy:generate --types in whatever hooks we need (ie: post-merge).

[wescopeland]

I wonder if it's possible to kick this off when either pnpm dev or pnpm build run. That may universally solve the problem.

[wescopeland]

This seems promising: https://github.com/orgs/pnpm/discussions/5758#discussioncomment-4329215

[wescopeland]

This feedback will likely be redundant from the button -> a comment I left earlier, but when clicking on things in tests, always best to use await userEvent.click(button). This simulates a real user asynchronously clicking on stuff rather than firing a browser event.

[wescopeland]

Still need to use a userEvent.click() here.