Enhancement: Target Oriented Documentation (starting from installation )

[ido777]

What features would you like to see added?

The current documentation seems like trying to meet all the different needs, however, as a newcomer it is very hard to read and sometimes even misleading.

It seems that it is time to start refactoring the documentation for a need.

As Google put it in their excellent book "Software Engineering at Google".

It was common in the early days of Google for teams to have monolithic wiki pages with bunches of links (many broken or obsolete), some conceptual information about how the system worked, an API reference, and so on, all sprinkled together. Such documents fail because they don’t serve a single purpose (and they also get so long that no one will read them; some notorious wiki pages scrolled through several dozens of screens). Instead, make sure your document has a singular purpose, and if adding something to that page doesn’t make sense, you probably want to find, or even create, another document for that purpose.

More details

Here is an example to explain where I am coming from, I wanted to install the project and start changing the code with minimal effort and maximal ease. There are some parts of the technological stack that I am less familiar with (as most of the people coming to the repo, I guess).

I tried Docker Compose installation as well as Dev container but it didn't work for me, easily.

Why?
I wanted to change the code and that the APP would change automatically, but after some effort I gave up.

Why?
The Docker compose and the dev container are using different volume definitions (why not unite?). the docker in the root copies the code (COPY . /app) so this is no go for my goal and the dev container regardless to the fact that it crashed my WSL on Windows, and that dev container is not documented at all in the project documentation. it didn't recompile automatically when I changed something.

So I think there should be different documentation for a full life cycle for a developer (e.g Debugging/Testing FrontEmd/BackEnd) using different IDE (e.g. vs code) etc.

Which components are impacted by your request?

No response

Pictures

No response

Code of Conduct

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

[danny-avila]

I understand. Dev setup for the repo is not fully documented in general. In fact, I would not recommend docker for dev work, and instead use npm and node while connecting to Mongo/Meilisearch using docker or using their remote services. This is part of the reason the devcontainer is not well documented. I don't use it, and it was added by people who do but didn't document it well.

[ido777]

Ok, however the docker compose is the recommended option according to the documentation. If the simple Linux is more documented / supported/used maybe it should be the more recommended.

[danny-avila]

Docker is mainly recommended for general use of the app, not for development.

[danny-avila]

When I update dev instructions, they will reside here which recommends local setup: https://github.com/danny-avila/LibreChat/blob/main/.github/CONTRIBUTING.md

[ido777]

IMO changing CONTRIBUTING.md is one option, but creating "dedicated" documentation for the developer with the appropriate headers, links, tags as well emphasizing the use case in the current documentation (e.g. general use) in current documents is another option that from my POV has pros as I tried to explain above

[fuegovic]

We do have a section dedicated to this in our docs: https://docs.librechat.ai/contributions/index.html

as well as a this guide which is more user friendly: https://docs.librechat.ai/contributions/how_to_contribute.html
but looking at it, I admit that some instruction on how to setup the dev env, how to deploy and test, seems to be missing.

While existing, I agree that the whole dev section of our docs would indeed benefit from more contributions