Do Not Confuse Polyfills With LibrariesIf you are using any utility library that brings you something similar to
requestAnimationFrameunder a different namespace that is not the
globalobject, that is not a polyfill but rather a library you have dependencies based on, and this is OK!
Polyfills Do Not Want MaintenanceIndeed, polyfills are scripts usually placed upfront the main application that should be removed when time is right, which means ASAP, without requiring indirectly any update, upgrade, or change from your own module.
Polyfills Aren't Virtually NeededYou don't want to
require('latest-browser-or-nodejs');in your code, because that is pointless, no matter if you use a
browserifyapproach, no module should contain a polyfill and here is why:
Global PollutionYes, polyfills are usually greedy because being polyfills they fill the environment gap, where the environment is usually not confined in your own closure.
Deadly ObtrusiveIf your module defines its logic behind some feature detection and including another module could change this, you are basically dropping an undesired bomb in your system you were not aware of the moment your module acted as it should ... as module, library, whatever it is, that didn't include a bloody obtrusive AMD that changed everything the module knows before that ... I mean, the moment your module is defined, that's the env you expect.
Always Upfront!Polyfills should have the exclusive position on top of anything you are developing because the day you won't need them you'll simply drop them and everything else will keep working lighter and faster.
Making your polyfill usable as a module won't benefit anything based on it for the simple reason that such modules won't be portable without a potentially not needed/necessary anymore environment normalizer, and need at that time extra maintenance form something assumed to work as that in such environment.
Delegate DependenciesIf your module depends on some polyfill just say so ... any other module that depends on your one might need or rely same polyfill too so don't make such polyfill your own choice .. and once again, if it does not change globally the behavior, it's NOT a polyfill ... in such case, feel free to include it!
What About browserify ?It's OK to publish modules to npm or bower so that it's possible to create a build task that will include polyfills in the right order, if needed, using
require('dom4')and others upfront.
However, if you did the mistake to wrap your polyfill inside an UMD and the
definelibrary is around, being the inclusion of modules completely arbitrary in terms of order, you might cause troubles not only for your own logic, but also for all other modules that were expecting, as example, the
window.TCPSocketto be there. Fix it dropping any UMD logic around your polyfill, and publish again ;-)