The current JS ecosystem leans heavily on bundlers and packers to enable this kind of workflow, and IMO it's a good thing that we do.

For example, lodash (a somewhat common set of utility functions and general helpers) is a single package, but internally it's broken up into hundreds of individual packages which lean on the dependency module system to resolve among themselves, deduplicate, and enable the ability to include only a few of them (and their dependencies) if you only need those in a project.

Many libraries are setup like this, because there's not much of a reason not to. Adding complicated functionality to an existing package is often worse for everyone than just creating a new package which implements what you want and setting it as a dependency.

As a counterpoint: I have a reasonably complex app that gets data via WebSocket pub/sub and dashboards it, does things like stream logs from remote devices, open up SSH consoles, draw canvas diagram with network map etc. It’s split up into lots of component files and I think I still have less than 50 files. So no, I would not say 1000 file app is normal (which is not to say they are not doing something grand that justifies it).

With my app size I can get away with no Webpack, just a Makefile that links together required file list into a template file, which is then included into the page template on the backend.