As far as I can see, Moodle uses RequireJS (AMD) for module loading throughout. But lots of the modules contain a universal module definition, which supports both AMD and CommonJS module loaders, with CommonJS usually being checked first. So when another script is included that defines the CommonJS module/exports objects, those modules can end up being added to that loader rather than the require loader.
On our Moodle site, this lead to "No define call" exceptions thrown by RequireJS, which could not find the module definition that was snatched away by CommonJS! With the 3rd party script being loaded asynchronously and in parallel to Moodle's core scripts, this exception did not occur every single time, but very often, nevertheless.
Similarly, a 3rd-party module containing its own global AMD-module loader would cause the same issue.
Possible workarounds for us are now:
- Fix the 3rd-party script to avoid using a global module loader or to add a namespace to it.
- Change the UMDs of the affected Moodle modules to ignore CommonJS module loaders.
I think you should consider removing the UMDs altogether and adding a namespace to your global require and define functions to avoid such issues in the future. A plugin that clashed with Moodle due to its own global require function did exactly that.