This makes the package smaller.
Before this change:
added 981 packages from 1497 contributors [...]
53M etherpad-lite-win.zip
After this change:
added 734 packages from 1043 contributors [...]
43M etherpad-lite-win.zip
Closes#3651.
Do not touch vendorized files (e.g. libraries that were imported from external
projects).
No functional changes.
Command:
find . -name '*.<EXTENSION>' -type f -print0 | xargs -0 sed -i 's/[[:space:]]*$//'
When nodejs 8.9.0 was released, its bundled npm version was 5.5.1 (see
https://nodejs.org/en/download/releases). It makes sense that we lover our
requirement to that version.
Please note that the npm version mentioned here does not refer to the npm
library installed as Etherpad dependency in node_modules via package.json
(which indeed is higher) but is merely the npm version used to bootstrap the
installation when running installDeps.sh.
This change amends 9d35d15ae3 and its planning issue - #3424 - which were too
strict.
This change is only cosmetic. Its aim is do make it easier to understand the
async changes that are going to be merged later on. It was extracted from the
original work from Ray Bellis.
To verify that nothing has changed, you can run the following command on each
file touched by this commit:
npm install uglify-es
diff --unified <(uglify-js --beautify bracketize <BEFORE.js>) <(uglify-js --beautify bracketize <AFTER.js>)
This is a complete script that does the same automatically (works from a
mercurial clone):
```bash
#!/usr/bin/env bash
set -eu
REVISION=<THIS_REVISION>
PARENT_REV=$(hg identify --rev "${REVISION}" --template '{p1rev}')
FILE_LIST=$(hg status --no-status --change ${REVISION})
UGLIFYJS="node_modules/uglify-es/bin/uglifyjs"
for FILE_NAME in ${FILE_LIST[@]}; do
echo "Checking ${FILE_NAME}"
diff --unified \
<("${UGLIFYJS}" --beautify bracketize <(hg cat --rev "${PARENT_REV}" "${FILE_NAME}")) \
<("${UGLIFYJS}" --beautify bracketize <(hg cat --rev "${REVISION}" "${FILE_NAME}"))
done
```
This is documented to be more performant.
The substitution was made on frontend code, too (i.e., the one in /static),
because Date.now() is supported since IE 9, and we are life supporting only
IE 11.
Commands:
find . -name *.js | xargs sed --in-place "s/new Date().getTime()/Date.now()/g"
find . -name *.js | xargs sed --in-place "s/(new Date()).getTime()/Date.now()/g"
Not done on jQuery.
Next version will be Etherpad 1.8. As planned in #3424, we are going to require
NodeJS >=8.9.0 and npm >= 6.4.
This commit implements that change and updates documentation and scripts.
Subsequent changes will get rid of old idioms, dating back to node < 0.7, that
still survive in the code.
Once migrated to NodeJS 8, we will be able to start working on migrating the
code base from callbacks to async/await, greatly simplifying legibility (see
#3540).
Closes#3557
In installDeps.sh we have a bunch of code (from 2011) that checks for the
existence of jQuery and eventually downloads it, but since 1239ce7f28 (year
2012) jquery is vendorized in /src/static/js/jquery.js.
Also, stop mentioning curl as a dependency in the README.md
Fixes#3494
This is a modification of PR #3474 by rohieb <rohieb@rohieb.name>.
When this script is run after an update, and something fails during the npm
run, the installed plugins were deleted, too.
In this version what gets deleted is only the directory that contains the
direct dependencies of the core Etherpad, ie:
node_modules/ep_etherpad-lite/node_modules
Currently, an Etherpad skin requires the existence of 6 files:
- index.{css,js}
- pad.{css,js}
- timeslider.{css,js}
In the default empty skin (in static/custom), there were 2 small placeholders
({js,css}.template) to be copied in place by the startup script in case no skin
was in use.
Now that we are moving to multiple directories (see #3471) we can simply commit
the example files and remove the copying code from the startup script.
Starting with Etherpad 1.7.0, the branching strategies for releases will be
simplified.
Leaving this script here, as it's useful for documenting other release-related
activities.
installDeps.sh's only side effect should be to actually install dependencies
according to a configuration file, and not to modify it.
Adding --no-save to the npm command line forces npm to have a read only access
to package.json.
Old npm versions seem to support --no-XXX style flags even if not documented
(see https://github.com/npm/npm/issues/14285#issuecomment-254298519)
Tested with npm 3.5.2 and 6.1.0
Fixes#3396
Otherwise, when inserting a multiline changelog sed would with this message:
sed: -e expression #1, char 27: unterminated `s' command
And the script would continue with an unmodified CHANGELOG.md
For simmetry, added the same check to package.json, too
At the end of run, `exec` should be used to switch to the node process. That way node will take over the pid of `sh run.sh`, making it easier to monitor and daemonize the server.
```
exec [command [arg ...]]
Unless command is omitted, the shell process is replaced with the
specified program (which must be a real program, not a shell
built-in command or function). Any redirections on the exec com-
mand are marked as permanent, so that they are not undone when
the exec command finishes.
```
Achieve 10x speedup in migrating a 12mb dirtyDB file by disabling
ueberDB caching in this special case. Add some progress messages
to the migration script and rename it, as nothing in it is tied
to mysql.
Simplified the cloning process, added validation checks to ensure the
new pad ID is valid and that a pad doesn't already exist with that ID.
Also fixed a bug in the chatHead cloning loop and added the ability to
specify a pad ID on the command the line (defaulting to the original
"-rebuilt" pad ID formula)
This script gives an admin with shell access the ability to restore a
pad at a given revision by essentially rebuilding it at a new location
with data associated with the original pad. The upsides to creating a
new pad vs. changing the original are: 1) avoiding service disruptions
(no deletes, no moving targets - builds from previous revision); and 2)
preservation of data (no deletes, no overwriting of the source pad).
The most obvious downside is the pad has a new ID which could require
folks to update their links, bookmarks, etc. to point at the new
location.