Compiled type wrong when using `list[str] | None`

[Leeward Bound]

Hello, I have put together a simple demonstration of my issue:

• When using a field of type list[str] | None, I expect the matching TS type to be Array<string> | null
• However, the observed output in models.ts is actually string | null (not a list)
• If I remove the | None optionality from the field, the TS type matches Array<string> as expected; adding support for the optional variant breaks the list typing definition.

Demonstration -
On the left, you can see my HomeController with a single field in HomeRender "COMPILES_TO_WRONG_TYPE".
In the middle on top is the output models.ts with the incorrect (singular) string | null type.
In the middle bottom, my view outputs JSON.stringify(COMPILES_TO_WRONG_TYPE).
On the right, you can observe that the value for this is correctly a list; only the typing definition from models.ts is incorrect.

I believe this is related to the handling in convert_schema_to_interface but I don't have much more time to debug at this moment.

https://github.com/piercefreeman/mountaineer/blob/main/mountaineer/client_builder/build_schemas.py#L126

Thanks so much for Mountaineer, it's a very cool approach, it solves a ton of my frontend/backend pain points, and I'm eager to experiment more with it - keep up the great momentum and someday I hope to join a mountaineer fanatics chatroom, donate to your beer money, or even send some PRs!

[Pierce Freeman]

Thanks for the report and the reproduction case @leewardbound. I've put up a PR to fix in #92. Will do some more testing tomorrow to make sure it handles even more extensive edge cases.

In the meantime, glad you're liking Mountaineer! Let me know if there's anything you'd like added to the docs that would make your onboarding experience easier. Excited for the ecosystem to develop more fully.

[Leeward Bound]

I have a couple of ideas w/r/t the docs and onboarding, this github comment feels like a weird place to aire them :) But since you asked -

I've been tinkering nights-and-weekends over the last 2-3wks; my primary hurdle in onboarding was auth. I like the stated goal of being "batteries included"; to me, this means docs ought to cover Auth and Users - either a pluggable approach in the framework (like Django's get_user_model), or at least bake in some basic editable boilerplate Login/Logout flow into the create-mountaineer-project flow for each author to modify themselves.

I've seen you mention the outdated plugins approach and link to some deprecated code in other Issues; I was able to piece together my own auth middleware by reading these examples, and the 4 page FastAPI "How To: Auth" docs, but it wasn't easy - this is the key missing boilerplate that will slow down every early adopter trying to put out an MVP with your framework.

I like simplicity this framework gets from serving backend and frontend from the same port and domain (in dev and in prod) - enabling good practices like HTTP-only cookies and never storing JWTs in the frontend - and eliminating common concerns arising from having separate frontend/backend apps using a traditional REST/gql API (security and configuration headaches, CORS issues, auth-in-SSR-API-requests, etc). Showcasing an opinionated implementation of that as a first-class feature would be really exciting.

[Pierce Freeman]

Thanks for the thoughts! Agree authentication is important.

I don't imagine auth will ever make its way into the core library, just because the choices are so personal to the project (what's your security posture, do you need to accept mobile API calls, etc.) What I can do is put together a tutorial for how I like to think about authentication and give an example of some of the building blocks that I've used in the past to build mountaineer-based login systems. This should get you to the same level as that V0 plugin architecture did. I'll put that on my list.

For the specifics of this ticket, I released v0.4.1.dev1 to fix this bug and add additional support for more typehints. Give it a try if you can. Should make it into stable shortly.