Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop shading and relocating dependencies #51

Open
kezz opened this issue Apr 19, 2024 · 0 comments
Open

Stop shading and relocating dependencies #51

kezz opened this issue Apr 19, 2024 · 0 comments

Comments

@kezz
Copy link

kezz commented Apr 19, 2024

This is very confusing and odd practice for a library. It makes the experience of using this library very poor for a number of reasons:

  • Having duplicate classes in the classpath makes the development experience bad, as anyone using IDE autocompletion features, refactoring, etc. will have duplicates of every common dependency (which includes the entire Kotlin stdlib in this example).
  • It needlessly bloats the size of the jar. Any project that shades in posthog-java, or uses it in other contexts, will have the file size bloated due to duplicate files.
  • It makes it impossible to update the libraries that this library uses. Some of the libraries, such as json-java, are out of date, meaning that performance improvements and bug fixes are missing and there is no way to update them without forking the library and updating them manually. See Critical security dependencies in this lib #46 for an example of an issue that required an entire update to the library, rather than simply adding a more up-to-date version of the library in the consumer's build files.
  • Some of the libraries used have issues when relocating (Kotlin doesn't play nicely sometimes) which can cause confusing bugs when developers accidentally use the relocated versions of files (even if they don't already have them in the class path).

The original reason for shading (#22) doesn't make much sense (the issues that the develop faced were not elaborated on and possibly could have been fixed in their build system) and it doesn't feel like it's a good reason to make this library worse because of it.

I would suggest reverting the change and would be happy to make a PR for this if desired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant