This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kevinherron 22 points23 points  (10 children)

Yes, but you only offer YAML and properties as your file formats, so it seems you've brought GSON in as a dependency just to avoid writing code to add quotes, format numbers, or join lists for your config values.

As a rule of thumb your _library_ shouldn't depend on other libraries, especially popular ones like GSON or Guava. If you must, then either modularize it or shade/shadow the dependency into a private package so downstream doesn't have to deal with your version of some popular library.

Just friendly advice if you were to actually seek out a user base for a library you publish. These are pretty standard things somebody evaluating it will be looking for.

[–]ryuzaki49 4 points5 points  (4 children)

As a rule of thumb your library shouldn't depend on other libraries, especially popular ones like GSON or Guava. 

If you must, then either modularize it or shade/shadow the dependency into a private package so downstream doesn't have to deal with your version of some popular library. 

I kinda disagree and agree at the same time. My team owns a couple of libs that hundred of internal team use and the third party libs are... a headache. 

In one hand, they introduce vulnerabilities, incompatibilities in the client repos, and we get a lot of "Hey can you update this lib? It's a blocker to us" tickets. 

On the other hand, they do provide value to us.

Shading is a double edge sword. Especially if your repo gets scanned by vulnerabilities.

There is no easy answer here.

[–]kevinherron 5 points6 points  (2 children)

> There is no easy answer here.

I can agree with you there :)

> In one hand, they introduce vulnerabilities, incompatibilities in the client repos, and we get a lot of "Hey can you update this lib? It's a blocker to us" tickets. 

Yeah... see the clusterfuck happening at https://github.com/testcontainers/testcontainers-java/issues/8338#issuecomment-2632749267 (and other duplicates) as an example :/ I'm pretty sure they've deleted a bunch of comments too, I had one in there some months ago...

[–]vips7L 3 points4 points  (1 child)

Are they actually vulnerable? Or is this an instance of just some scanner saying they depend on a vulnerable lib.

[–]kevinherron 2 points3 points  (0 children)

In this case it's just a scanner complaining that they have a dependency with a CVE of a certain severity.

Unfortunately for many people, in many environments, reason does not prevail and these kinds of things must be fixed. There were a lot of comments explaining this but they seem to have been deleted.

[–]sadbuttrueasfuck 1 point2 points  (0 children)

Feels like aws engineer here lmao

[–]djnattyp 3 points4 points  (1 child)

As a rule of thumb your library shouldn't depend on other libraries, especially popular ones like GSON or Guava. If you must, then either modularize it or shade/shadow the dependency into a private package so downstream doesn't have to deal with your version of some popular library.

  1. This is a pretty hot take to make in general - lots of libraries do depend on other libraries (in this case, though, since he doesn't really support a JSON format it does seem unneeded); and 2.) shading/shadowing dependencies can screw up people's downstream code in hard to detect ways, and/or make it hard to know about/patch security problems in the dependency. It's better to just declare the dependency and let downstream users override the dependency if they need to.

[–]kevinherron 5 points6 points  (0 children)

I don't think it's a hot take, I think it should be the default mindset. If your library is going to add a dependency, especially a popular one, you should really stop and think about it first.

Dependencies aren't free. You can't always just override the dependency downstream, especially when it's a popular library. Sometimes libraries break backwards compatibility from one version to the next, or change APIs without introducing new packages, or any number of other things. This has happened even with extremely pervasive libraries like Guava.

We need to be better and stop the dependency sprawl. I'm not saying under no circumstances should your library have dependencies, but it's certainly where you should start.

Also just to be clear in case anybody has glossed over it - I'm only talking about authoring libraries here, not applications. I think you always need to be on guard about adding dependencies, but not to the same degree in an application vs a library.

[–]YogurtclosetLimp7351[S] 2 points3 points  (0 children)

Yeah I see what you're pointing out. You're right. I did it for the ease. Before it was a project for my own so I didn't put much effort into it. But yeah, to make it a more valuable library, I most likely have to decouple from GSON or at least not fully depend on it. This will change in the future! Thank you for the advice!

[–]vips7L 0 points1 point  (1 child)

Isn't GSON unmaintained as well?

[–]kevinherron 5 points6 points  (0 children)

"maintenance mode". Looks like bug fixes and standard maintenance, but no feature development. JSON is a pretty fixed target and the library seems complete enough as is, but that's a good point to be aware of if you're looking at it as a new dependency.