Of course you can write your own code, but you will be in a bubble then and "works for me" will be something that you say very often.
On the other hand maintaining this code means that you need to have quite solid tests for it, which means that it would be easier to just separated in a module.
Modules are published on npm. Yeah there are lots of them.
On my open source projects, for example, I perform a huge ton of test automation. My application run in browsers, but I don't provide any test automation for the browser environment. I just manually test there occasionally. The effort is too high and the environment is so simple that I can get what I need from brief manual testing. Since the code that runs in the browser (and its documentation) is dynamically assembled maybe half the concerns there are solved by testing the code in other environments more conducive to test automation.
Rationally speaking you don't really need to provide 100% test coverage. You just need to provide enough tests to guarantee the application does all it claims to do.
> Of course you can write your own code, but you will be in a bubble then and "works for me"
That is what test automation and feature tests are for. The application does all it claims to do or it doesn't regardless of whether you wrote original code or cobbled together various untested packages.
I do the same.
But I must admit, nearly every time I manually test on a different browser, some behaviour or other is different in some broken way, and I spend a while updating the code to handle yet another browser difference.
Perhaps I'm pushing the edge a bit with the sort of things I write, but still. It's astonishing how much variation there is.