This is precisely the kind of generalisation that many experienced developers will rightly object to.
There is absolutely nothing unreasonable about manually downloading a specific version of a small number of self-contained libraries, and just using them either directly or integrated into some sort of bundling process. This has significant advantages in terms of simplicity, reliability, and transparency compared to the who-knows-what that NPM and its ecosystem will generate only to achieve the same end result.
You only really need to use NPM if you're working with lots of small packages and/or packages that have many small dependencies of their own, but either way, now you have two problems.
I'll probably do that in my "utility" library to keep my actual application project as light as possible. But I'm not going to add a dependency for 4 lines of code, as much as I may appreciate the effort you took in providing them. See https://github.com/btomala/akka-http-twirl/blob/master/src/m... for a recent example.
Would it be fair to say you didn't understand the web frameworks very well?
I'm not sure that lines of code is a great measure here. What about test coverage? Maintainability? NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're programming in.
It sounds like you had an expansion of the web team. It only makes sense that you'd standardise things when that happens. It just happens they weren't standards you are familiar with.
There's a perception among "server boys" (or are you "server men" looking over the "web boys"?) that the web doesn't deserve 15,000 lines of code. It's a lot more complex than you give it credit for - or would you be happy to write all your backend code in C and C only?