#1304 - Force JS libs to load in 'browser' mode

[TomByrne]

Forced JS includes to load in 'browser' mode, instead of trying to use 'module.exports' which was causing problems with electron/webpack.

See issue for more info.

[player-03]

Copying relevant comments from the issue. TomByrne said:

Including these files as part of the Lime js output seems to be problematic when running in electron. This is because most js libraries detect whether they're running in a 'module' based environment (e.g. node/electron/webpack) by checking whether the global props 'module', 'exports' or 'define' exist (mostly using 'exports'). If so, then the library will treat the module.exports object as it's own export space, potentially totally clearing exports and populating it with it's own methods (as pako does - module.exports=f()). It also will often not include it's own namespace wrapper in this mode, assuming that webpack/node will do that, this is a problem because pako's functionality (for example), ends up at module.exports.inflateRaw, with no pako wrapper. This means that js libraries included through Lime (and running in electron) will be adding their functionality to the same object, in same cases removing functionality from other included libs.

The resolution to this that I've found is to 'fool' the libraries into thinking that they're running in a regular old browser context, where typically they'll add their functionality into a namespace object on the global/window object (e.g. window.pako = {...}). This is done by running them in a function that first has: var module=undefined,exports=undefined,define=undefined;.

Obviously this isn't guaranteed to work for all libraries but was working for us with Howler/pako/FileSaver. Has also been tested after webpacking, which wasn't working since 7.3.

And jgranick responded:

How can I reproduce this issue?

lime test electron appears to work fine using the latest Lime and the Pirate Pig demo -- no Pako or Howler issue.

Does this occur when running another command to package the application?

Finally, peteshand responded:

Thanks for looking into this Joshua. After a bit more investigation I think it's related to some auto reload logic being fired to early

...And closed the issue.

[player-03]

Interesting. Both libraries seem to use CommonJS modules rather than the newer EMCAScript ones. Presumably for legacy reasons.

Looks like Node automatically converts between the two types, but browsers don't. That's a shame; it would have been nice to let the browser take care of keeping things separate.

---

While both Howler and pako might not need module.exports, some library out there might rely on it. Perhaps we could save module.exports after loading each library, then clear them for the next one. The exact implementation would be a bit tricky.

Also, while both Howler and pako might work fine in strict mode, some other library might not, so I don't think we should put the libraries inside the "use strict" function.

[player-03]

Huh. Odd that I never reviewed the file conflict. d969c7fa30aab14042c5e59ae525ab3a5c2679ca attempts to add support for AMD. Or perhaps it tries to prevent AMD from working?

I can't help but feel that there ought to be a better way.

Edit: looks like that commit is related to issue #1328. There, Joshua mentioned wanting to overhaul how libraries are handled, which I fully agree with.