I think it depends on the observable effect of the upgrade to a consumer of your component.

Did the dependency upgrade just improve performance? fix a bug? Add a new capability? Remove a backward compatible feature?

Certainly doesn’t automatically follow that if a dependency upgrade adds a feature, that that is a feature addition in your code, because you haven’t changed your code to use the new feature. But it could be - if you upgraded a parser library so it now supports strings longer than 4K, maybe your component now supports strings longer than 4K too and that merits a minor version bump.

It can be a pretty subtle judgement - especially with potentially deep dependency trees like are common in node.

If you’re bumping a dependency because the dependency has bumped one of its dependencies… can be tricky to figure out if there’s actually a noticeable effect.

That's "chore" in my company. The scope is usually the component (frontend/backend/etc.).

Is it a "public dependency"? In that case with a breaking change for your crate if it's a breaking change in the dep.

I use build type with scope of the package manager. For example:

build(poetry): update alembic dependency to 1.7.0

according to angular docs build is

build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)

so using build for things that affect /src seems wrong.

I was with you till the last line. Npm and Poetry are fulfilling the same role of external dependencies, what am I missing here?