Jakob AckermannandClaude Opus 5
7ae8db6b12
* [editor-core] share the pieces the editor, real-time and history-v1 all need Project-level history-OT has the browser, real-time and history-v1 all reason about the same changes, so the rules they reason with move into the shared library rather than being reimplemented on each side. - `origin/editor_origin.js` plus `EDITOR_ORIGIN_KIND` and its schema entry: the origin an editor client's change carries, holding the editorId that scopes a change's timestamp. - `change_identity.js`: how a submission is recognised when it comes back, so a resend of a change that already landed is deduplicated rather than applied twice. - `rebase.js`: transforming a change onto concurrent ones, in the same order on both sides, which is what lets the server acknowledge a change with only the version it landed at. - `text_file_defaults.js`: the doc-vs-file extension lists, now read from here by web's settings instead of being spelled out again. - `blob_string_length.js`: the string length of a blob, used by history-v1's blob store and by web when it writes an uploaded file into history. - `file_tree_diff.js`: file-tree operations to a diff, used by project-history's FileTreeDiffGenerator. - `Blob.EMPTY_HASH`, so callers can answer for the empty blob without storing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * [project-history] build the file-tree diff with the shared helper FileTreeDiffGenerator's hand-rolled walk over add/edit/move/delete operations becomes a call to `buildFileTreeDiff` from overleaf-editor-core, so the editor and project-history read a file-tree change the same way. Adds the unit tests the decaffeinated original never had. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * [web] read the editable-file lists from overleaf-editor-core web's settings spelled out the text extensions and editable filenames that decide whether a file becomes a doc, and every other service that has to make that call carried its own copy. The lists now live in overleaf-editor-core and web builds settings.textExtensions and settings.editableFilenames from them, keeping the ADDITIONAL_TEXT_EXTENSIONS override for Server CE/Pro on top. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * [history-v1] read a blob's string length from overleaf-editor-core Two copies of getStringLengthOfFile lived here, the one in recover_zip.js carrying a TODO asking for exactly this. Both now import the shared implementation, which the blob store keeps re-exporting for backupArchiver. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> GitOrigin-RevId: 31948332f416f56848e3b0dfb5142a4c9f93f508
@overleaf/project-history
An API for converting raw editor updates into a compressed and browseable history.
Running project-history
The app runs natively using yarn and Node on the local system:
yarn install
yarn run start
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 install # Only needs running once, or when yarn packages are updated
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_ARGS='--grep=AuthorizationManager'
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 install # Only needs running once, or when yarn packages are updated
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_start_service
make test_acceptance_run # Run as many times as needed during development
make test_acceptance_stop_service
make test_acceptance just runs these three commands in sequence.
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_ARGS='--grep=AuthorizationManager'
Makefile and yarn scripts
The commands used to compile the app and tests, to run the mocha tests, and to run the app are all in package.json. These commands call out to coffee, mocha, etc which are available to npm in the local node_modules/.bin directory, using the local versions. Normally, these commands should not be run directly, but instead run in docker via make.
The makefile contains a collection of shortcuts for running the yarn scripts inside the appropriate docker containers, using the docker-compose files in the project.
Copyright (c) Overleaf, 2017-2021.