* tests: Restore `runnerBackend.sh`
`runnerBackend.sh` was deleted in commit
7dae5e3db8 but plugins still need it
until their GitHub workflow definitions have been updated.
Co-authored-by: John McLear <john@mclear.co.uk>
Patch-specific release branches should never diverge from the tag, so
they serve no useful purpose. (If they do diverge, which some did
before I deleted them all, what does it mean? Are we going to move the
tag in the future? It's just too confusing.)
In the future we might want to do major- or minor-specific
branches (e.g., `release/1` or `release/1.8`), but only if we want to
maintain old releases. For example, if 2.0 is a major release that
doesn't work with plugins designed for 1.x we might want to maintain a
`release/1` branch that continues to get bugfixes while the bulk of
new work continues to land on `develop`. If we do decide to maintain
old releases we'll need a new set of release scripts (or edit the
`release.js` script on the `release/1` branch).
Also add symlinks from the old `bin/` and `tests/` locations to avoid
breaking scripts and other tools.
Motivations:
* Scripts and tests no longer have to do dubious things like:
require('ep_etherpad-lite/node_modules/foo')
to access packages installed as dependencies in
`src/package.json`.
* Plugins can access the backend test helper library in a non-hacky
way:
require('ep_etherpad-lite/tests/backend/common')
* We can delete the top-level `package.json` without breaking our
ability to lint the files in `bin/` and `tests/`.
Deleting the top-level `package.json` has downsides: It will cause
`npm` to print warnings whenever plugins are installed, npm will
no longer be able to enforce a plugin's peer dependency on
ep_etherpad-lite, and npm will keep deleting the
`node_modules/ep_etherpad-lite` symlink that points to `../src`.
But there are significant upsides to deleting the top-level
`package.json`: It will drastically speed up plugin installation
because `npm` doesn't have to recursively walk the dependencies in
`src/package.json`. Also, deleting the top-level `package.json`
avoids npm's horrible dependency hoisting behavior (where it moves
stuff from `src/node_modules/` to the top-level `node_modules/`
directory). Dependency hoisting causes numerous mysterious
problems such as silent failures in `npm outdated` and `npm
update`. Dependency hoisting also breaks plugins that do:
require('ep_etherpad-lite/node_modules/foo')
John McLear