When taking the modular javascript approach for development, with Node.JS + npm and browserify to bundle up to the browser, how is it possible to deal with a situation where you may need to use javascript libraries that are not distributed in npm? Eventually these libraries are not even compatible with modularity (amd/commonJs), since they don't expose anything in a modular way. Some of them exist in bower, I understand that for those cases there are resources such as browserify transform debowerify, but that won't be of any help if the intended library itself does not behave like a module.
So, what I'm also trying to figure out is: once you've taken the path of modular javascript through node.js + npm modules, does it take out of reach the use of any library that's not modular compatible?
Let me put a concrete example:
I have and main.js entry point for an app (npm package knockout installed), with code like:
var ko = require('knockout');
I know that when this ko variable gets to the browser via browserify, it is not tied to the global scope, but has its own scope, essentially trapping everything defined in that knockout file/module loaded by npm.
I then I have a 3rd party library that is not a node module, that delivers dom manipulation through the use of knockout. I would have to provide that pre-requisite for the 3rd party library as an additional explicit <script> tag referencing knockout on my html file, this way hooking it to the global (window) scope. I would then have knockout in two places, but isolated from each other. For example, a ko.applyBindings inside my main.js would be unkown to the other library that relies on knockout on the global scope.
How (if possible at all) would my modular javascript implementation handle the co-existence of dom manipulation in these both sides? Or for this case is it a mutually exclusive programming pattern that has to be adopted (all modules or all non-modules)?
