OT: but letting it stand as it's a good explanation and is broadly useful even in JS circles.
----
I have one difference of opinion on SOLID, if you're writing projects in JS with JS Modules... the D (Dependency Injection) may not be necessary. You can use module substitution techniques for testing, and unless you absolutely are supporting multiple concurrent types of modules with your application, wire them directly to keep the code more simple and easy to reason with.
Time and time again, I see DI libraries for JS that really aren't needed and only serve to add unnecessary complexity.
----
On BDUF, it doesn't need to be Waterfall... If I'm creating a package for a library/service, I will often start on the README.md first and include the documentation on how to use the library *BEFORE* I start writing code. This lets me think about the abstractions for that library and how it will be used in practice before I paint myself into a corner. It can also help with TDD and some test-first approaches.
I tend to only really use this approach for libraries that can be abstracted away from the rest of an application.