Don't add feature X that other log library might add or has added, your lib is bad. Add a feature X that other log library has, now you support it for the lifetime of universe. Oh and RCE might happen.
It all starts with little changes.
Allow us to show colors in console...
Allow us more formatting options...
We need to display remotely added class...
We need JNDI access...
You added a feature that can load plugins and query any kind of data based on user provided strings, this is completely unexpected and never happened before. What to call it? How about SQL injection attack, sounds about fancy enough.
If you implement feature requests without thinking about the design and security implications it has you are doomed to repeat history.
> Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns.
Good luck auditing that.
.m2/repository is 5 gb on my machine.
Rust crates?
Go packages that are neatly tucked away too?
Node just makes it visible and in your face by putting the node_modules in you project directory.
Besides, what’s the alternative? Write stuff yourself? Put stuff in language stdlib? Even minimal service requires _a lot_ of things to do minimal stuff.
There are ways to manage this sort of stuff.