e039ad26c5
* [editor-core] hold the one threshold that decides which store owns the file tree HISTORY_FILE_TREE_STAGE is five literals across the services that consume this library -- web backend, web editor, real-time, third-party-datastore, github-sync -- linked by comments saying which other copies they are aligned with. What the docstring here says is what goes wrong: this is the single thing that decides which storage is authoritative, a project crosses it once with no way back, and a copy that drifts sends a whole service's writes to the store nothing reads any more. Silently, and for good. overleaf-editor-core is where it goes: every one of the five already depends on it, the editor included, and the library that defines what a file tree is can say where one lives. The consumers adopt it separately; this is the definition they adopt. historyIsSourceOfTruth goes with it, and refuses a stage that is neither absent nor a number rather than reading it as low -- web's copy coerced, which turned a corrupt stage into a permanent mongo write. Absent stays "below the gate": a project that never migrated has no stage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * [editor-core] hold which doc a project opens on History records it as `main: true` on the file, and nothing derives it: every writer that creates a project has to record it, or the project compiles nothing until the user picks a file. So the rule for choosing one, and the operations that record it, go where a file tree is defined rather than with any one writer. The rule is the one web has always applied, over a snapshot instead of a mongo tree: of the docs that declare a document class, the one nearest the project root, alphabetically among equals, so that the same files always give the same answer. A project that already records a root doc keeps it -- that is a user's choice and not something to re-derive. Whether a doc could be the one is asked of content rather than of a store to read it from: a writer creating a project has each doc's content in its hands as it stores it, so reading them back would be a second read of every one. The choice is then made from the pathnames alone. The extension list joins the others in text_file_defaults for the reason they are there: a writer holding a shorter copy leaves a project with nothing to compile. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * [editor-core] say why a store built for a consumer does not need getBlob ReadWriteBlobStore is BlobStore without the lookup by hash, and the type said so without saying why a consumer can do without it. getBlob is reached only for a file stored as a bare hash, and one of those does not leave history-v1: chunk_store's lazyLoadHistoryFiles attaches blob metadata to every snapshot and change it serves, so a file arrives already knowing its own lengths. That is what the contract rests on, and a store that reimplemented the classification rule to answer the lookup anyway would be a second opinion on whether a file is editable. The reasoning was what was missing, rather than the type. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * [editor-core] say what makes a doc a root doc candidate The sentence naming the two halves of the check had lost the first one, and read "named as a root doc may be named". It is the extension that is tested: one of DEFAULT_ROOT_DOC_EXTENSIONS, and a document class declared in the content. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * [editor-core] hold the doc flags a file's metadata can carry in one place `main` is not the only flag a doc carries -- `mainBibliography` marks the file references are added to -- and both live in the same metadata, which SetFileMetadataOperation replaces wholesale rather than merges. So every writer that sets one has to write the others out again, and every reader that asks whether a file is a doc has to know the whole list. root_doc was spelling all three of those for itself against `main` alone: it tested the key by hand, refused a file whose metadata held anything else, and cleared the metadata to `{}` when moving the root doc elsewhere. Against a file that is also the main bibliography, the first two refuse a legitimate root doc and the third silently drops the bibliography. The helpers answer it once: which keys are doc flags, whether metadata holds only those, and what metadata with one flag changed looks like. root_doc uses them throughout, and the schema takes both flags on one file. Co-Authored-By: Mathias Jakobsen <mathias.jakobsen@overleaf.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * [editor-core] ask the snapshot which doc carries a flag Finding the file a doc flag is set on is the same search whichever flag is being asked about, and it belongs to the snapshot rather than to the caller: it walks the snapshot's own pathnames, and it is the snapshot that knows a file's metadata without its content being loaded. root_doc's mainPathname is that search for `main`, and now delegates. It gains the check it was missing: a file whose metadata holds anything besides doc flags came from outside the editor, so a stale `main` on it does not make it the root doc -- which is already what setMainPathnameOperations refuses to write. Co-Authored-By: Mathias Jakobsen <mathias.jakobsen@overleaf.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * [editor-core] drop mainPathname for the snapshot method behind it It became a second name for `snapshot.getPathnameWithDocFlag('main')` and nothing in the library was left calling it but chooseRootDoc, which asks the snapshot directly now. Its two tests go with it: Snapshot's own cover the same two answers, and more of them. Callers outside the library ask the snapshot too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Mathias Jakobsen <mathias.jakobsen@overleaf.com> GitOrigin-RevId: b3f503aa3e94ea8b6524d83f910fe33dc381c0a5
An open-source online real-time collaborative LaTeX editor.
Wiki • Server Pro • Contributing • Mailing List • Authors • License
Figure 1: A screenshot of a project being edited in Overleaf Community Edition.
Community Edition
Overleaf is an open-source online real-time collaborative LaTeX editor. We run a hosted version at www.overleaf.com, but you can also run your own local version, and contribute to the development of Overleaf.
Caution
Overleaf Community Edition is intended for use in environments where all users are trusted. Community Edition is not appropriate for scenarios where isolation of users is required due to Sandbox Compiles not being available. When not using Sandboxed Compiles, users have full read and write access to the
sharelatexcontainer resources (filesystem, network, environment variables) when running LaTeX compiles.
For more information on Sandbox Compiles check out our documentation.
Enterprise
If you want help installing and maintaining Overleaf in your lab or workplace, we offer an officially supported version called Overleaf Server Pro. It also includes more features for security (SSO with LDAP or SAML), administration and collaboration (e.g. tracked changes). Find out more!
Keeping up to date
Sign up to the mailing list to get updates on Overleaf releases and development.
Installation
We have detailed installation instructions in the Overleaf Toolkit.
Upgrading
If you are upgrading from a previous version of Overleaf, please see the Release Notes section on the Wiki for all of the versions between your current version and the version you are upgrading to.
Overleaf Docker Image
This repo contains two dockerfiles, Dockerfile-base, which builds the
sharelatex/sharelatex-base image, and Dockerfile which builds the
sharelatex/sharelatex (or "community") image.
The Base image generally contains the basic dependencies like wget, plus texlive.
We split this out because it's a pretty heavy set of
dependencies, and it's nice to not have to rebuild all of that every time.
The sharelatex/sharelatex image extends the base image and adds the actual Overleaf code
and services.
Use make build-base and make build-community from server-ce/ to build these images.
We use the Phusion base-image
(which is extended by our base image) to provide us with a VM-like container
in which to run the Overleaf services. Baseimage uses the runit service
manager to manage services, and we add our init-scripts from the server-ce/runit
folder.
Contributing
Please see the CONTRIBUTING file for information on contributing to the development of Overleaf.
Authors
License
The code in this repository is released under the GNU AFFERO GENERAL PUBLIC LICENSE, version 3. A copy can be found in the LICENSE file.
Copyright (c) Overleaf, 2014-2025.