* [github-sync] Surface "project too large" errors instead of hanging A GitHub sync of a project whose total editable text exceeds github-sync's 7MB request body limit would hang silently: the modal stayed on "Importing and merging changes in GitHub" and then closed with no error. Root cause was a chain of three issues: 1. github-sync's ErrorMiddleware did not recognise the body-parser PayloadTooLargeError, so it fell through to a generic 500. 2. web's _reportError rethrew any non-4xx error instead of responding, and several github-sync controller handlers were not wrapped in expressify. On Express 4 the rethrow became an unhandled rejection and no HTTP response was ever sent, so the browser request hung until the socket died. 3. the frontend read error.data.error without a null check, which threw a render-time TypeError when the fetch failed at the network level (as it did once the hung request was aborted). Fixes: - github-sync: add ProjectTooLargeError and map the body-parser 413 to it. - web: _reportError always responds (500 for unexpected errors) and every controller handler is expressified as a backstop. - frontend: null-safe error.data?.error, a friendly message for the too-large case, and a generic message for server errors. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * [github-sync] Refine project-too-large error copy per content guidance Apply the content-design system's error-message guidance to the new github_project_too_large_error string: use a contraction, drop the redundant "reduce the size of your project" restatement and the formal "Please", keeping the problem/reason/next-step structure. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * [github-sync] Use plain string matcher in project-too-large CT test Address review feedback: prefer a plain string matcher with exact:false over a regex, per the repo's testing guidance. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * [github-sync] Link to the file-limits docs from the too-large error Add a "Learn about GitHub sync file limits" link below the project-too-large error, pointing to the GitHub synchronization file-limits documentation, so users can find out what the limits are and how to stay under them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * [github-sync] Use rel="noopener noreferrer" on the file-limits docs link The eslint rule for external docs.overleaf.com links requires rel="noopener noreferrer" (not just noreferrer) with target="_blank" to prevent reverse-tabnabbing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> GitOrigin-RevId: 16f701a85fb4ae049c208e03e328ad80049e8579
overleaf/web
overleaf/web is the front-end web service of the open-source web-based collaborative LaTeX editor, Overleaf. It serves all the HTML pages, CSS and javascript to the client. overleaf/web also contains a lot of logic around creating and editing projects, and account management.
The rest of the Overleaf stack, along with information about contributing can be found in the overleaf/overleaf repository.
Running the app
The app runs natively using yarn and Node on the local system:
$ yarn install
$ yarn run start
Running Tests
To run all tests run:
make test
To run both unit and acceptance tests for a module run:
make test_module MODULE=saas-authentication
Unit Tests
The test suites run in Docker.
Unit tests can be run in the test_unit container defined in docker-compose.tests.yml.
The makefile contains a short cut to run these:
make test_unit
During development it is often useful to only run a subset of tests, which can be configured with arguments to the mocha CLI:
make test_unit MOCHA_GREP='AuthorizationManager'
To run only the unit tests for a single module do:
make test_unit_module MODULE=saas-authentication
Module tests can also use a MOCHA_GREP argument:
make test_unit_module MODULE=saas-authentication MOCHA_GREP=SSO
Acceptance Tests
Acceptance tests are run against a live service, which runs in the acceptance_test container defined in docker-compose.tests.yml.
To run the tests out-of-the-box, the makefile defines:
make test_acceptance
However, during development it is often useful to leave the service running for rapid iteration on the acceptance tests. This can be done with:
make test_acceptance_app_start_service
make test_acceptance_app_run # Run as many times as needed during development
make test_acceptance_app_stop_service
make test_acceptance just runs these three commands in sequence and then runs make test_acceptance_modules which performs the tests for each module in the modules directory. (Note that there is not currently an equivalent to the -start / -run x n / -stop series for modules.)
During development it is often useful to only run a subset of tests, which can be configured with arguments to the mocha CLI:
make test_acceptance_run MOCHA_GREP='AuthorizationManager'
To run only the acceptance tests for a single module do:
make test_acceptance_module MODULE=saas-authentication
Module tests can also use a MOCHA_GREP argument:
make test_acceptance_module MODULE=saas-authentication MOCHA_GREP=SSO
Routes
Run bin/routes to print out all routes in the project.
License and Credits
This project is licensed under the AGPLv3 license
Stylesheets
Overleaf is based on Bootstrap, which is licensed under the
MIT license.
All modifications (*.less files in public/stylesheets) are also licensed
under the MIT license.
Artwork
Silk icon set 1.3
We gratefully acknowledge Mark James for
releasing his Silk icon set under the Creative Commons Attribution 2.5 license. Some
of these icons are used within Overleaf inside the public/img/silk and
public/brand/icons directories.
IconShock icons
We gratefully acknowledge IconShock for use of the icons
in the public/img/iconshock directory found via
findicons.com