Comments URL: https://news.ycombinator.com/item?id=48368121

Points: 683

# Comments: 283

Comments URL: https://news.ycombinator.com/item?id=43938889

Points: 2

# Comments: 0

You can subscribe by clicking on Watch -> Custom -> Releases.

It's true that dependency-free software is very rare these days. The most obvious reason is that people don't want to "reinvent the wheel" when doing something. While this is a 100% valid reason, sometimes people simply forget what they are building and for whom. Extensive usage of dependencies is just one of the forms of overengineering. Some engineering teams even do their planning and features because of the new shiny thing.

The problem of dependencies is massive these days, and most companies are focusing on producing more and more code instead of helping people manage what they already have.

In short, people either update too frequently or don't update at all.

So, I decided to create a simple linter that checks all the main issues and best practices, comes with sensible defaults, and allows you to adjust it to your needs.

It supports npm/yarn, Go, pip, and Cargo. Any feedback is welcome!

Comments URL: https://news.ycombinator.com/item?id=42654412

Points: 1

# Comments: 0

PH is still a great platform for visibility since it gets tons of traffic.

Comments URL: https://news.ycombinator.com/item?id=41798311

Points: 2

# Comments: 0

> HN allows resubmission of links if they haven't had any discussion. Source: https://news.ycombinator.com/item?id=9864254

But it seems like it was just a comment/speculation, and it has nothing to do with the guidelines that you added. Thanks for pointing it out!

I decided to create DepsHub to solve these particular problems:

- Update noise. There is no need to update EVERY single library all the time. Your project should be relatively up to date with all the major packages updated and no security issues.

- Automatic major updates. Breaking changes occur all the time, and LLM are quite good at this point to take the changelog changes and apply them to the codebase automatically.

- Observability. I want to know what's the current status of all of my repositories, how outdated they are, and what I need to do to make it better. This is quite a new niche that not a lot of products are focusing on.

DepsHub is processing thousands release notes and changelogs, converting your codebase to embeddings and applies LLMs to fix any breaking changes that occur. It also uses some additional analysis to understand if the library is actually needed to be updated (some libs are having new versions every week!).

Let me know if you have any questions or suggestions. Any feedback is more than welcome!

Website: https://depshub.com/

Comments URL: https://news.ycombinator.com/item?id=41074230

Points: 4

# Comments: 11

Every single team that I worked with always used tens (if not hundreds) of dependencies. There are usually two popular options: either you ignore the dependencies problem until it's too late and hard to migrate everything to newer versions (say hi to vulnerability issues), or you're constantly trying to find the balance between working on a product and doing its maintenance.

I decided to create DepsHub to solve these particular problems:

- Update noise. There is no need to update EVERY single library all the time. Your project should be relatively up to date with all the major packages updated and no security issues.

- Automatic major updates. Breaking changes occur all the time, and LLM are quite good at this point to take the changelog changes and apply them to the codebase automatically.

- Observability. I want to know what's the current status of all of my repositories, how outdated they are, and what I need to do to make it better. This is quite a new niche that not a lot of products are focusing on.

DepsHub is processing thousands release notes and changelogs, converting your codebase to embeddings and applies LLMs to fix any breaking changes that occur. It also uses some additional analysis to understand if the library is actually needed to be updated (some libs are having new versions every week!).

Let me know if you have any questions or suggestions. Any feedback is more than welcome!

Website: https://depshub.com/

Comments URL: https://news.ycombinator.com/item?id=41071162

Points: 1

# Comments: 0

Every single team that I worked with always used tens (if not hundreds) of dependencies. There are usually two popular options: either you ignore the dependencies problem until it's too late and hard to migrate everything to newer versions (say hi to vulnerability issues), or you're constantly trying to find the balance between working on a product and doing its maintenance.

I decided to create DepsHub to solve these particular problems:

- Update noise. There is no need to update EVERY single library all the time. Your project should be relatively up to date with all the major packages updated and no security issues.

- Automatic major updates. Breaking changes occur all the time, and LLM are quite good at this point to take the changelog changes and apply them to the codebase automatically.

- Observability. I want to know what's the current status of all of my repositories, how outdated they are, and what I need to do to make it better. This is quite a new niche that not a lot of products are focusing on.

DepsHub is processing thousands of changelogs and release notes, converting your codebase to embeddings and applies LLMs to fix any breaking changes that occur. It also uses some additional analysis to understand if the library is actually needed to be updated (some libs are having new versions every week!).

Let me know if you have any questions or suggestions. Feedback is more than welcome!

Website: https://depshub.com/

ProductHunt launch: https://www.producthunt.com/posts/depshub-2

Comments URL: https://news.ycombinator.com/item?id=41065891

Points: 3

# Comments: 0

This is exactly what I've added for depshub.com, and people seem to like it a lot. It just gives you better visibility across all of your connected repositories about what the current status of each dependency is and how the major vs. minor vs. patch ratio changes over time. While it's still a naive metric, it's the easiest to understand and visualize - and as a result, the one that is used the most.

> Any ideas on how we can measure improvements?

- Quantitative: Spend as little amount of time as possible on trying to keep everything relatively up to date (hours/month) - Qualitative: not having any CVE issues, not having major updates for core libraries and tools.

What happens if the library that you're using is completely fine on its own (think React 18) but it's a core cross-dependency for tons of other libraries in your project. No libraries or frameworks should be considered in isolation. Otherwise, it can lead to a situation where you can't use some of the other tools/libraries, etc., because of the other dependency that is quite out of date.