But it's 35 LOC because it's probably not handling various cases that aren't obvious at first. That particular package went through many versions and is widely used so there's a chance it's robust and will be maintained over time. That's one less maintenance task to do.

I have took a look at that particular package ([edit] not really, see below), and it seems to be a very short code, grown into more lines by providing API for configuration (delay, smooth or not, duration, offset etc.) and various convenience wrappers for easy mixing-in into your components. It also implements scroll-spy behavior. Versions (and open issues) are mostly about adding/changing/fixing yet another of those convenience wrappers.

If you do a lot of scrolling into various components on various actions on your page, this module can sure be handy. Otherwise, it doesn't really seem to do anything better than a simple snippet copy'n'pasted into proper place. Those "non obvious at first cases" in this case seem to be mostly about how developer uses it in their code, so if you just use it in one place to do one specific thing, there are none.

[edit] Oh, sorry! I saw "react-scroll", while the article mentions "react-scroll-to-component". This one actually consists of 32 LOC and there's nothing more to it! It depends on "scroll-to", which is 66 LOC, but most of it is due to formatting and API and could be probably squeezed into a few lines without losing much clarity. Then it depends on a "tween", which actually does the smoothing and could be the one thing actually worth depending on, if that's what you need to achieve. In simplest cases it boils down into a one-liner as well, but it's a well-known library anyway.

"scroll-to" also depends on "raf", which is a polyfill you might or might not need.

35 LOC is absolutely worth a package, unless your package manager is really bad; that means 34 fewer lines in your codebase.

Well, yeah, 32 fewer in your codebase, 28 fewer in your build, 10 fewer that you have to type, 15 more you have to understand, 37 more you have to debug...

Watch out for actively developed dependencies.

I'd say rather: approach a dependency upgrade like any other code change, and be prepared to refactor aggressively (including by copying code and removing the dependency, if necessary) as with any other code change.

Is having 100 dependencies bad?

As someone who audit code for a living, yes it is bad oO that would be a nightmare to go through