While I'm sure it was well intended, using window as the name of the export target argument in the quintusCore function turns out to be a problem when using front end bundlers like Browserify or Webpack. The existence of module.exports does not negate the possibility that window will also exist (later, during browser runtime).
My change simply gets rid of the window function argument and replaces it with exportTarget. The only place exportTarget actually gets used is when var Quintus gets attached. All other references to window in this file invariably refer to the actual browser window global, which is no longer overridden, so we can leave those be.
The only problem now is that we run a shim for setAnimationFrame which might try to act on a window object that might not exist. It's fundamentally silly anyway to try to add this when we're on the server side, so I just made that shim exit early if window's type is 'undefined'.
While I'm sure it was well intended, using
windowas the name of the export target argument in thequintusCorefunction turns out to be a problem when using front end bundlers like Browserify or Webpack. The existence ofmodule.exportsdoes not negate the possibility thatwindowwill also exist (later, during browser runtime).My change simply gets rid of the
windowfunction argument and replaces it withexportTarget. The only placeexportTargetactually gets used is whenvar Quintusgets attached. All other references towindowin this file invariably refer to the actual browserwindowglobal, which is no longer overridden, so we can leave those be.The only problem now is that we run a shim for
setAnimationFramewhich might try to act on awindowobject that might not exist. It's fundamentally silly anyway to try to add this when we're on the server side, so I just made that shim exit early ifwindow's type is'undefined'.