Updating the client or api code in deployment and recreating the docker will not update the content

[ido777]

What happened?

I followed the documentation https://docs.librechat.ai/deployment/docker_ubuntu_deploy.html#part-iv-editing-the-nginx-file-for-custom-domains-and-advanced-configs
updated the client code, recreated the deploy-compose.yml dockers but the change was not reflected in the dockers so I wasted 2 days to understand why it does not work.

After wasting a lot of time and doing a long research I learned the very hard way that it is actually written in the doc itself some line down the road as a shaded note.

Note that any changes to the code in this environment won't be reflected because the compose file is pulling the docker images built automatically by GitHub

This Note is very easy to miss especially since the guide suggests to create a branch and commit it the new branch and do:
"

npm run rebase:deployed
You should be all set!

"
and only after you are all set - then comes the note. (It should have been before the all-set and much more visible, mainly since it is a surprising note when you are just explained to commit to a branch and do a rebase as a system, while the truth is that it will only work for the file in the example !!!)

The bug is not the documentation, per see - it only adds oil to the fire, Given the fact the docker-compose is the recommended installation and deployment, you might think that this is the recommended way to develop, which today IMO is problematic, to say the least, not only that there is no good documentation for setting up for development, but the dockers system has many bugs (will open issues for specific issues later)

Steps to Reproduce

1. Follow the guide https://docs.librechat.ai/deployment/docker_ubuntu_deploy.html#part-iv-editing-the-nginx-file-for-custom-domains-and-advanced-configs
2. Change something in the client as well not only the nginx conf file as in the doc
3. Do a npm run rebase:deployed
4. Your client file change will not be seen...

What browsers are you seeing the problem on?

No response

Relevant log output

No response

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[fuegovic]

This seems to be more of a user error than anything else, in my opinion. Logically, the code will not update if you pull an image, which makes sense upon reflection. This is the reason why most people avoid doing development work directly with Docker. Even when setting the docker-compose file to build, the process of rebuilding to test every change is too time-consuming and doesn't make sense 🤷‍♂️.

[ido777]

Dockers have a lot of advantages and when they are set correctly they SAVE time (in the initial setup and in every build).
I saw more than once that the docker cache mechanism works better than many other build system take for example bazel cache when compiling huge (>3G) source files
I don't know about npm - but we will know this once we fix the dockers :-)

[fuegovic]

I don't know about npm

Using npm eliminates the need to rebuild entirely. It allows you to observe live changes made to both the frontend and backend, making it the preferred method for development.

[ido777]

Yes you are right, it is user error than anything else, however, the code setup is not intuitive and nothing hints that + in the documentation there is a whole section that explains how to change the code but the example it uses to change the code is the only file that this procedure works for, moreover there is a dedicated command for this file but the command name give you the impression that it supports all changes.

But my main point is this: fixing the way the dockers works + clearer documentation could help avoid such misunderstandings in the future. An alternative is not to define the docker as the recommended was of the project.

[fuegovic]

...the code setup is not intuitive and nothing hints that......

We do assume a foundational understanding of the tools and processes involved. Given the complexity of the project, this baseline knowledge is pretty much essential for any modifications.

An alternative is not to define the docker as the recommended was of the project.

Docker is favored for LibreChat due to two key reasons:

• Consistent Environment: Docker ensures the same environment across different stages (development, testing, production).
• Packaging Dependencies: It allows bundling MongoDB and Meilisearch alongside the app for easy deployment.

[ido777]

I was in the middle of trying to explain why Dockers should be the favored way ... when I saw your message...

So we agree Docker is favored for LibreChat. right?
So how come most of the LibreChat people avoid doing development work directly with Docker?

The answer is that the docker is set in a non common way, different than industry standard.
That is what I suggest to fix.

[fuegovic]

As previously explained, development is conducted using npm because it is faster, not due to any unconventional docker setup. The docker container utilizes npm internally; however, it is quicker and more straightforward to work directly with npm and then conduct tests using docker. This approach is quite standard.

[berry-13]

@ido777, are you suggesting that Docker is faster than npm or bun in live-changes updates 🤔? if yes, can you provide an example of what we should change? thanks