* Merge all .prettierignore files into top-level config * Merge all .prettierrc files into top-level config * Replace service-specific glob patterns in package.json format scripts with `prettier .` * Add template files with Jinja2, Go template, envsubst, and Handlebars syntax to .prettierignore * Ignore GitHub templates * Ignore PUG templates to format them separately with `format:pug` * Encourage double quotes for YAML, YML files * Move prettier for PUG source format script to the root * Move prettier for styles source format script to the root * Remove prettier for jenkins files from web * Remove prettier source format script from all services * Make .prettierrc more readable * Update format scripts by file type * Organise `.prettierignore` * Add `--cache` flag to prettier scripts for faster runs * Format all files with prettier * Format all or format services * Remove `format`/`format:fix` scripts from services since now it runs from root `package.json` * Avoid conlficts with yamllint configuration * Remove `--cache` flag from prettier scripts * Update all service Makefiles to use root-level prettier configuration * Update all Jenkinsfile to use root-level prettier configuration * Ignore auto-generated files by build_scripts * Update package-lock.json * Update root Makefile format targets * Update SP Jenkinsfile format target * Update E2E Makefile format script * Udpate `format_js` to work in both local and CI env * Add docker-mailtrap to .prettierignore docker-mailtrap is a third-party git-ignored directory used for testing * Added Docker env detection to prevent nested Docker spawning * Ignore handlebars templates * Add cryptographic files and test output to `.prettierignore` * Add terraform modules to `.gitignore` * Remove prettier-plugin-groovy * Use npx directly instead of Docker for local formatting for faster formatting * Auto-generate Makefiles * Revert "Remove prettier-plugin-groovy" This reverts commit 194a33589a2e1e4d2225d10c67e9f025e4222025. * Mount monorepo root in RUN_LINT_FORMAT for prettier config access * Prettier ignores all `node_modules` by default regardless of location * Show only changed files in format output * Ignore LICENSE files * Enable prettier on rendered build_scripts outputs * Ignoring all the template folders by prettier * Remove the public/minjs entry since it does not exist * Remove all non-existent paths * Sync `.prettierignore` with ignored files by `.gitignore` and `.dockerignore` files * Revert "Auto-generate Makefiles" This reverts commit c0233e490de1bc95fe437219d65e0b66e0331ec9. * Revert "Use npx directly instead of Docker for local formatting for faster formatting" This reverts commit 1d2b2cf1a6c6974c76885852a90dd55e84167e41. * Ignore dashboard JSON files * Ignore files generated by bin/update_build_scripts * Remove unsupported file types from `.prettierignore` * Ignore test fixture generated files * Ignore README file types by prettier * Ignore generate snapshots by prettier * Allow to format generated bin/update_build_scripts by prettier * Ensure build script outputs prettier-compatible tsconfig.json * Fix build script output to match prettier formatting - Fix Jinja2 whitespace in docker-compose templates - Change YAML quotes from single to double * Don't read cryptographic files by prettier * Ignore google verification files by prettier * Revert npx prettier formatting * Ignore domain verification files * Show only changed files in format output * Make `.github` prettier * Allow all files to be formatted in jobs by prettier * Allow server-ce/server-pro files to be formatted by prettier * Ignore more folders in clsi, filestory, git-bridge by prettier * Update build script with `RUN_LINTING_CI_MONOREPO` * Ignore docker-mailtrap and downloads in server-ce by prettier * Restore prettier configs and prettierignore for V1 since it has its own prettier (an older version) * Source format GitOrigin-RevId: 637adc3cc422d1f20c86d6ebc8ec514d60758287
Migrations
Migrations for the app environment live in this folder, and use the East migration framework.
We have a npm script which wraps east: npm run migrations -- ...
For example:
npm run migrations -- list -t 'server-ce'
For SAAS, use the rake tasks for staging/production
rake deploy:migrations:list[staging]
Environments and Tags
Overleaf is deployed in three different environments:
server-ce: community edition installations (the base system)server-pro: server pro installationssaas: the production overleaf site
All migrations are tagged with the environments they should run in.
For example, a migration that should run in every environment would be tagged with ['server-ce', 'server-pro', 'saas'].
When invoking east, we specify the relevant tags with the -t or --tags flag.
Our adapter will refuse to run if this flag is not set.
Creating new migrations
To create a new migration, run:
npm run migrations -- create <migration name>
This command will create a new migration file in the migrations folder, based on a template. The template provides
migrate and rollback methods, which are run by the east binary when running the migrations. rollback should
undo the changes made in migrate.
Running scripts as a migration
To run a script in a migration file, look at migrations/20190730093801_script_example.js, which runs the script
scripts/example/script_for_migration.mjs. This uses a method where the script can be run standalone via node, or
through the migrations' mechanism.
Running migrations
To run all migrations in a server-ce environment:
npm run migrations -- migrate -t 'server-ce'
# Note: They are run by default on container start.
To run all migrations in a SAAS environment use the rake task:
# list first and check that only your newly added migration is shown. If not, ask in the dev channel for help.
rake deploy:migrations:list[staging]
# After confirming the listing, run the migrations
rake deploy:migrations[staging]
To run all migrations in the dev-env:
make services/web/migrate
# Note: "make install" will pick them up as well
The -t flag also works with other east commands like rollback, and list.
For other options, or for information on how to roll migrations back, take a look at the East documentation.
Tips
Try to use Mongo directly via the db object instead of using Mongoose models. Migrations will need to run in the
future, and model files can change. It's unwise to make the migrations depend on code which might change.
Note: Running east rollback without any arguments rolls back all migrations, which you may well not want.