I always laugh when some developer has an “epiphany” that following long-established best-practice is no longer necessary. Best practices don’t materialize out of thin air — they exist because real problems happen during large-scale projects maintained by large teams, and they emerge as really smart people try to find ways to avoid those problems in future projects.

All that’s happened here is you’ve hit the part of your learning curve where you don’t yet know enough to go faster following best practice than putting your code together with chewing gum and duct tape.

You’re absolutely right that SOLID isn’t the right set of best practices for ES6, though. And let’s look at why that is. The import statement pretty much makes Liskov substitution impossible, and in many instances that also means dependency injection becomes difficult (there’s an amusing subset of Javascript articles where the author believes that what we had before DI is now dependecy inversion, just because they have no sense of the history). Look instead at GRASP (General Responsibility Assignment Software Patterns). They’re not a perfect match, because again the language is working against us, but a somewhat better fit.

I think if you follow TDD well, you will in general have well-designed software, because your code will be split into discrete, testable units and your dependencies will be injected because that’s easier to test. But, again, we have a new crop of developers who have “discovered” TDD isn’t necessary and tools like Jest snapshotting, which does a great job of proving components do what they do.

But just as skipping tests gives you the illusion — for a while — that you’re going faster, skipping good design is a way to get velocity that’s fake. And it kind of sucks to realize that when you’re spending weeks untangling a rat’s nest and trying to figure out how to update the design of something that is used in 100 places.