etherpad-lite: still big, or building / running instructions are not updated?

As you can see in this issue, I tried to help. If you’d open a bug report like “Don’t include azure modules by default” or “Large amount of storage on default installations” I’ll happily discuss further steps or help you with onboarding to be the next developer. I don’t expect Pull Requests or that everybody is a NodeJS developer. I know that people have different skills. That’s why I welcome your thoughts even if I don’t put your thoughts on my top priority list.

However, it seems to me that you are not here to help Etherpad or comment on bugs in Etherpad, but because your “cute test task” that you want to show to your customers has caught your attention due to unexpected storage consumption. Now you want us to fix this ASAP and because this does not work you are getting angry.

If you want more people to listen to your ideas, I’d recommend you work on your communication skills.

@f1-outsourcing

Could you please stop offending and blatently attacking other maintainers. We are currently 3 people trying to maintain a project that even went through Google’s supervision and contains a lot of code that is not optimized/documented.

Why didn’t even Google do that? They are one of the Fortune 500 companies. If you spend some time and/or money we could find a full time developer that moves this project to a more efficient statically linked binary which would be a lot more efficient in terms of CPU/memory/image size.

So the bottom line is: Either start throwing hundreds of dollars at this project so that we can find someone that can do this as his/her lifetime or you need to make your hands dirty yourself. Learn Rust/Go and we can talk again how we want to move Etherpad forward.

Until then we three do our best effort to maintain and support etherpad-lite while paying the power bill for running our dev machines.

Do you want to talk about how such a configurator should work or do you just want to propose that someone should write this configurator? I would be +1 for a minimal size version of Etherpad, if the effort is moderate. Thoguh, as storage is cheap, I have other priorities.

For some dependencies it might be straight forward, e.g. publish a ueberDB version that only supports Postgres or Mysql and change package-lock accordingly. But in general this is not the way NodeJS projects work. Search the internet for “node_modules why large size critique” etc. and there is plenty of discussions around the whole topic.

Avoid installing dev dependencies has the largest effect, we probably should make this default, as most users don’t want to develop Etherpad.

If you care from an operational standpoint I would rather suggest to use a file system with compression and or de-duplication on the data sets that store the project’s files.

As said, I appreciate conceptual contributions, but they should not be too out of scope, e.g. let’s not depend on cmake or autotools to prepare our package-lock.json.

@f1-outsourcing I’d be happy to see a pull request from you with some proposed changes 😃

cd src && npm ci --omit dev --omit optional results in 210 MB

cool thanks, I will try this. If you would revert this, and have in the Dockerfile/home page statements that include modules. Then it is more obvious what can be commented out for someone that is not familiar with npm. There are so many development environments you can’t assume any more that users just ‘know stuff’. With just a bit of logics you can deduct what needs to be comment out.

Mostly I am using your etherpad as a test task in the container environment, and it is sort of cute to have this functionality. But if it gets big I might as well create an small images with python -m SimpleHTTPServer $PORT0

If you add export NODE_ENV=production it could get even smaller. Other than that you could also fork ueberdb, throw out the tests, dev dependencies and all database drivers that you don’t need and then build and publish that to your npm registry.