If the thing that slows down my programming is writing import statements by hand, then I have worse QA issues than that.
If the thing that slows down my programming is writing import statements by hand, then I have worse QA issues than that.
Modularity is good and all, but explicitly declaring each single dependent component (external libraries and other internal components) when writing new components and adding new ones as you need more dependencies is quite painful and tedious.
Up to a point though -- "break[ing] down functions into tiny components" doesn't seem to be on the good side of modularity, but more like the lpad npm fiasco.
So, my reply to that comes down to:
If you have so many imports that it costs you "so much time" to handle them manually, then you probably have QA issues -- like people adding tons of dependencies to your project.
But it was also meant in the way that if you code so fast, that manually adding some imports is what slows you down ("takes so much time") then probably you are not thinking about what you code enough.
Typically, even without automated imports, the time to handle imports would/should be a negligible amount compared to the time to write the actual functionality -- that's the difficult part, and that what takes one time to think, design and code right.
Or having to manually write "import React from "react"" on top of every single new component.
Or having to write "import _ from lodash" whenever you need to access _ for some function.