Upgrade deps, add storybook

[ukutaht]

Changes

Adds phoenix storybook dependency along with example pages for dropdowns and basic inputs. In order to make it work I had to upgrade some deps:

• phoenix_ecto to 4.5
• phoenix_html to 4.1
• phoenix_live_view to 1.0

There were some breaking changes which I'll take notes on in self-review

There are a couple known issues with storybook installation:

1. The storybook area (./storybook) uses its own JS bundle which is using pre-1.0 version of liveview. This causes a console warning but no real-world issues as far as I can tell. A new version of storybook should be released this week with support for Liveview 1.0
2. For some reason, when you navigate to a page with Alpine.JS component (Input -> Dropdown) it causes some error from AlpineJS. When you load the page with AlpineJS directly it works fine. I wasn't able to find a fix.

[ukutaht]

These should have been removed when we moved to esbuild. Modern phoenix config wants these JS packages to be resolved via mix ../deps folder but our package.json was actually shadowing the same deps in ./node_modules.

By removing from node_modules we have less config and guaranteed that the frontend package has the same version as the backend one.

[github-actions]

Preview environment👷🏼‍♀️🏗️
PR-4947

[aerosol]

Cool work 👏.

CI failures aside, I think this could benefit from being a MIX_ENV=dev-only dependency/runtime. Or do you intentionally want to run it on prod servers? IMHO it's unnecessary build clutter for prod images.

I've tried looking into the Alpine misbehavior, but Alpine-specific setup you did seems a-OK.

[ukutaht]

CI failures aside

About that - the new HeeX engine wants us to convert all the templates from <%= var %> to {var} with mix format. However this will make the PR much harder to review. I was thinking I'd wait to get reviews and push the mix format change at the last minute before merging.

I think this could benefit from being a MIX_ENV=dev-only dependency/runtime. Or do you intentionally want to run it on prod servers? IMHO it's unnecessary build clutter for prod images.

Yeah it feels like a dev thing to me as well but there were a couple points that made me include it in docker builds:

• I was thinking it would be nice to make the components easily accessible for Liina at https://plausible.io/storybook
• And also to be able to see in a preview environment when components are worked on and how they differ from prod: https://pr-4947.review.plausible.io/storybook/dropdown

Maybe just including in preview builds would be a good solution for now. But since preview builds are also made with MIX_ENV=prod it would only be a runtime exclude so not really address the 'build clutter' issue which I agree with. BTW I found that we have a couple instances in the codebase checking for MIX_ENV=staging which, as far as I can tell, is never the case.

Anyways - I definitely think having storybook in preview environments is useful but I'm agnostic about prod. Given all that - do you think we should exclude from prod at runtime?

[apata]

I think being able to view the storybook without running the app locally is an important part for its adoption: when following the storybook is inconvenient, it's unlikely to help in unifying user experience within the app.

That said, I'd also be wary of exposing it from prod servers: as I see it, the increase in attack surface / ways for our prod servers to fail is not worth the convenient plausible.io/storybook URL. Have it on staging?

[ukutaht]

I've pushed the large mix format commit.

PS: Merging this will likely cause conflicts with other PRs that change templates

[apata]

All seems to work as expected in the review env.