2011-06-02 13:15:02 +02:00
|
|
|
node_modules
|
2019-10-01 07:03:59 +02:00
|
|
|
/settings.json
|
2012-12-10 23:46:54 +01:00
|
|
|
!settings.json.template
|
2011-08-03 20:31:25 +02:00
|
|
|
APIKEY.txt
|
2015-04-11 22:22:00 +02:00
|
|
|
SESSIONKEY.txt
|
2011-08-11 23:00:52 +02:00
|
|
|
etherpad-lite-win.zip
|
2011-08-13 23:18:42 +02:00
|
|
|
var/dirty.db
|
2011-11-28 20:28:06 +01:00
|
|
|
*~
|
2012-02-04 18:46:43 +01:00
|
|
|
*.patch
|
2012-02-26 13:31:47 +01:00
|
|
|
npm-debug.log
|
2012-03-02 22:00:20 +01:00
|
|
|
*.DS_Store
|
2012-11-22 10:12:58 +01:00
|
|
|
*.crt
|
|
|
|
|
*.key
|
2015-12-02 12:53:41 +01:00
|
|
|
credentials.json
|
2017-09-14 13:33:27 +02:00
|
|
|
out/
|
2020-03-29 16:25:52 +02:00
|
|
|
.nyc_output
|
2020-04-23 18:54:12 +02:00
|
|
|
.idea
|
Delete top-level `package.json`
Advantages of a top-level `package.json`:
* It prevents npm from printing benign warnings about missing
`package.json` whenever a plugin is installed.
* Semantically, it is "the right thing to do" if plugins are to be
installed in the top-level directory. This avoids violating
assumptions various tools make about `package.json`, which makes
it more likely that we can easily switch to a new version of npm
or to an npm alternative.
Disadvantages of a top-level `package.json`:
* Including a dependency of `ep_etherpad-lite@file:src` in the
top-level `package.json`, which is required to keep npm from
deleting the `node_modules/ep_etherpad-lite` symlink each time a
package is installed, drastically slows down plugin installation
because npm recursively walks the ep_etherpad-lite dependencies.
* npm has a horrible dependency hoisting behavior: It moves
dependencies from `src/node_modules/` to the top-level
`node_modules/` directory when possible. This causes numerous
mysterious problems, such as silent failures in `npm outdated` and
`npm update`, and it breaks plugins that do
`require('ep_etherpad-lite/node_modules/foo')`.
Right now, with npm v6.x, eliminating the disadvantages is far more
valuable than keeping the advantages. (This might change with npm
v7.x.)
For a long time there was no top-level `package.json` and it worked
fairly well, although users were often confused by npm's benign
warnings. The top-level `package.json` was added because we needed a
place to put ESLint config for the stuff in `bin/` and `tests/`, and
we wanted the advantages listed above. Unfortunately we were unaware
of the disadvantages at the time. The `bin/` and `tests/` directories
were moved under `src/` so we no longer need the top-level
`package.json` for ESLint.
An alternative to a top-level `package.json`: Create
`plugins/package.json` and install all plugins in `plugins/`. If
`plugins/package.json` has a dependency of
`ep_etherpad-lite@file:../src` then plugin installation will still be
slow (npm will still recursively walk the dependencies in
`src/package.json`) but it should avoid npm's nasty dependency
hoisting behavior. To avoid slow plugin installation we could create a
lightweight `etherpad-pluginlib` package that Etherpad plugins would
use to indirectly access Etherpad's internals. As an added bonus, this
intermediate package could become an adaptor that provides a stable
interface to plugins even when Etherpad core rapidly evolves.
2021-02-05 01:47:57 +01:00
|
|
|
/package-lock.json
|
2021-02-05 00:43:27 +01:00
|
|
|
/src/bin/abiword.exe
|
|
|
|
|
/src/bin/convertSettings.json
|
|
|
|
|
/src/bin/etherpad-1.deb
|
|
|
|
|
/src/bin/node.exe
|
