Skip to content

Conversation

@ghivert
Copy link

@ghivert ghivert commented Oct 11, 2025

What ?

After iterations in #49, that PR finally propose a merge of the new Lustre's Frontend directly in Hexdocs repository as a first step to migrate the old frontend.

Because I don't really know your build process, I decided to keep the frontend somewhat isolated, while providing a full CI action running tests and build, to illustrate how to run tests and how to build the application. Indeed, the application is somewhat separated from the backend: in development it runs directly on its own local dev server (http://localhost:1234); when targeting production Lustre Dev Tools will generate 3 files: one HTML file, one JS bundle and one CSS file. They only need to be served from an HTTP server, alongside the assets (in the assets folder).

Applications built in two parts usually choose among two solutions:

  • Serve the frontend and backend from separate domains and handle CORS.
  • Combine everything directly in the docker image, and serve the files from the backend directly. (In that case, you can configure the Lustre dev server to proxy your request from http://localhost:1234 to the Hexdocs dev server http://localhost:4002 (in gleam.toml, tools.lustre.dev.proxy).

The application is built as an SPA, and can act on every subpath. For example, if the application will be hosted on https://hexdocs.pm, it can be served from https://hexdocs.pm, https://hexdocs.pm/search or even https://hexdocs.pm/whatever. The application will read the location from the browser, and acts in the correct manner. Every unknown paths will fallback to not_found. This opens the application to extension: adding new pages is only a matter of parsing the new locations, and implementing the pages directly in the Lustre application.


As a first step, I cleaned the code and the useless files to only keep the sources, tests and essential config files (and I removed every noise from the old repository). I'm open to any modification you'd need to better integrate in the repository, I really wanted to open the merge discussion, feel free to ask for anything!

@ericmj
Copy link
Member

ericmj commented Oct 15, 2025

Thanks @ghivert! This looks good at a first glance with the caveat that I have limited gleam experience.

We are currently working on getting a release pipeline for this so we can test it in staging. We will let you know when that's ready.

@ghivert
Copy link
Author

ghivert commented Oct 16, 2025

If you need additional modifications once your staging pipeline is added, feel free to ask, I'll do it as soon as I can! I'd love to finally push that new frontend live!

@Gazler
Copy link

Gazler commented Oct 16, 2025

If you want to keep the commit history of your project as well as be able to sync the project if you update your repo then you might want to consider using a git subtree. https://gist.github.com/SKempin/b7857a6ff6bddb05717cc17a44091202

Here's what it looks like as a diff:

https://github.com/hexpm/hexdocs/compare/main...Gazler:hexdocs:hexdocs/search-subtree?expand=1

@josevalim
Copy link
Member

@ghivert can you please send a PR to https://github.com/hexpm/hexdocs-static instead? Or are you fine with us doing that? The home page is actually served by hexdocs-static but we can do the grunt work. :) Thank you!

@josevalim
Copy link
Member

@Gazler I believe @ghivert's old repo will be sunset as well as the current hexdocs static, so just taking over the new main should be fine. :)

@ghivert
Copy link
Author

ghivert commented Oct 16, 2025

@josevalim I can for sure send you the PR on HexDocs static. If you prefer to do it on your side (for CI, pipeline, or whatever reason), I can give you the ownership, if the only concern would be my name/some commits in the commit history, I can live without this. 😁 My goal is to smooth your work as much as possible and help you deliver a cool HexDocs thing above all, so tell me what you do prefer, and I'll adapt to it.

To be honest, I rather dislike subtrees, as they're always harder to manage from my point of view, and I see no real value-added to keep the old commit history, but maybe you see something I can't! Also, I think it would be much better to archive my repo, and put everything under Hex organisation ownership. It was my goal since the beginning in my mind. Especially since other than me could end up modifying it, so it would makes no sense to keep it on my account!

@josevalim
Copy link
Member

@ghivert keeping the existing repo is perfect, given we will replace the existing one anyway! Can you please add me as admin to the existing repo? Then I can transfer it over :)

@ghivert
Copy link
Author

ghivert commented Oct 16, 2025

@josevalim Added you as collaborator! I'm not sure I follow what you want here. 😅 Should I make a PR to hexdocs-static in the end? Or do you prefer to keep my repo after transfer? In that case, I should probably clean it up a bit no?

@josevalim
Copy link
Member

Sorry, to be clear, we have two options:

  1. Transfer your repo as is to this org
  2. Start with a new repo (which I can create and then you PR in)

Which one do you prefer? It is 100% up to you!

@ghivert
Copy link
Author

ghivert commented Oct 16, 2025

Ha ha, no worry, I wasn't 100% sure so I preferred asking, but that was what I understand!

I transferred you the ownership, as it's actually not possible to add an admin on a personal repository! I think it's simpler if you need to keep the site as-is right now.

Tell me if you need some additional modification. 😄

@josevalim
Copy link
Member

It is here, thank you! https://github.com/hexpm/hexdocs-search

@josevalim josevalim closed this Oct 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants