Jakob Ackermann
37e27bb22e
* [monorepo] reduce writes from chrome in cypress Chrome puts its shared memory in /dev/shm, and docker's default 64MB is far too small for it - which is why Cypress passes --disable-dev-shm-usage, spilling those segments to files on the container's writable layer instead. Under one spec that is a few hundred MB of write-then-delete churn; under the CI fan-out it was most of the disk bandwidth on the whole box. So every service built from dockerfiles/cypress gets shm_size 1gb and every cypress config drops the flag again: the SaaS e2e service, web's CI and local component-test services plus its standalone cypress one, and server-ce's e2e and native cypress services. Both e2e-open variants inherit the setting through `extends`; the native one is a service of its own, and would be left running Chrome against 64MB once the flag is gone. * [monorepo] adopt cypress-pnp-reporter Materializing the reporter packages copied 267 packages / 3779 files (59MB) into /tmp on every container start, once per spec. Resolving them through PnP inside Cypress's Electron process instead drops that to zero: the entrypoint shell went from 55.6MB of write_bytes to 0. * [web] serve built assets from a prepared buffer between builds Serving a chunk cost ~2ms whatever its size, and an editor page pulls ~144 of them, so webpack-dev-server burned 2-3 cores through an e2e run purely answering requests for output that had not changed since the last build. It is not bytes: cutting the bundle 2.6x with a cheaper devtool moved CPU by 8%, and an empty 304 cost nearly as much as the full body. It is the per-request work - reading the asset out of the in-memory filesystem and re-hashing the whole body for a strong ETag, on every request. Three things a build does that this has to respect, each found by tracing the hooks rather than by reading them: - `done` fires twice per build, for the compilation and for the manifest, both with the same hash. A flag would have been cleared by the second while the first was still running, so the gate is a counter. - An incremental `done` reports only the assets it rewrote - 16, not 630 - so asset names accumulate. Resetting them on `invalid` left the manifest's two behind and nothing was served from here again. - webpack-dev-middleware holds requests during a rebuild. This sits in front of it, so it steps aside for that window and drops the cache when a rebuild starts. Whether a response can be kept is then decided as it ends rather than as it began: an epoch bumped on `invalid` names the build its bytes were read from, and only a response from the current build with no rebuild in flight is stored. A rebuild starting mid-response can no longer write the previous build's bytes in behind the cache being dropped, which eviction by asset name could not catch anyway - an incremental build does not name the assets it left alone. Measured on the editor entrypoint, 16 concurrent clients: 0.26-0.31s -> 0.045-0.050s of webpack CPU per page load, and 0.0455s immediately after a rebuild. Same chunk graph, byte-identical output. GitOrigin-RevId: 08b4ab2d665414069bc01b4763dd64faa9b4e5cb
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 TEST_NAME_PATTERN='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 TEST_NAME_PATTERN argument:
make test_unit_module MODULE=saas-authentication TEST_NAME_PATTERN=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 TEST_NAME_PATTERN='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 TEST_NAME_PATTERN argument:
make test_acceptance_module MODULE=saas-authentication TEST_NAME_PATTERN=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