Fix get_build_dir when custom_build is enabled

[lamylio]

Hello,

I've noticed that when custom_build is set in the configuration, the get_build_dir function doesn’t use local_target or packaged_target at all, causing Chainlit to return the same build path for both build_dir and copilot_build_dir. As a result, the static mount "/copilot" (server.py, line 225) does not point to the copilot directory, and the /copilot/index.js route doesn’t exist, making the copilot unavailable.

Currently, users can work around this by moving the copilot index.js file into the frontend’s dist folder. However, I believe it would be better to maintain the same structure as the one of the package, with separate folders for each component. Also, I don't feel it is necessary to have two separate (yet the same) parameters for the get_build_dir function.

Example structure:

- app
  - app.py 
  - .chainlit/
  - .files/
  - build/
    - copilot/
      - dist/
        - index.js 
    - frontend/
      - dist/
        - assets/*
        - index.html
        - favicon.svg

Before:
custom_build = "build" → doesn’t work at all
custom_build = "build/frontend/dist" → frontend works, copilot doesn’t (unless we move index.js to it)

After:
custom_build = "build" → both work (and seems more natural to me)

Feel free to modify the way I’ve implemented it if you see a better approach! :)
P.S. Haven't created any new tests, as at first glance the function didn't seem to be used elsewhere.

[dokterbob]

Thanks for the contrib @lamylio!

What I noticed trying to figure out that get_build_dir() is supposed to do is that there's actually not a clear specification of what custom_build is supposed to do; it's not documented anywhere (at least where I could find), other than ''custom build directory for the frontend' in the config. Yet, it is a public API -- so any changes to it's behaviour are likely to get some of our users in trouble!

Going forward, I'd like to improve on this! Let's first get clear on what custom_build is supposed to do, that is, documenting the specific use case(s) and steps required to use it. Can be here, we can use the discussion in this ticket to write a documentation section.

Based on that, I would like to have the documented use case(s) unit tested (so get_build_dir()) and the custom_build E2E test or your patch should be adjusted so it will pass. Breaking the test implies that we're breaking compatibility, so we should really consider whether it is necessary and worthwhile.

If (and only if) we're already changing the API, we might as well rename custom_build to something like custom_frontend and, correspondingly, get_build_dir() to get_frontend_dir().

Alternatively: we have frontend builds run automatically now for GIT-based installs. That implies that developers can simply fork the chainlit repo and install directly from there -- so technically there is no more reason to support serving a custom frontend from a different location.

@willydouhard Curious what your thoughts are, and perhaps to have more insights into design decisions that lead to the current API.