RequireJS should work with LS (use of requirejs will not pass salesforce security review if you are ultimately looking to publish your package to appexchange though). Requirejs is also not LC lifecycle (rendering/event loop) lifecycle which is the other reason we created ltng:require.
Please keep in mind that Lightning Platform itself has a long stabnding security mandated restriction on CSP script-src that only allows your external javascript resources to be retrieved from Static Resources - this means no matter what you use (and also independent of Locker) no scripts can be retrieved from non Salesforce CDNs.
ltng:require is already compatible with the common module registration pattern of:
(function (global, factory) {
typeof exports === 'object' && typeof module !== 'undefined' ? factory(exports) :
typeof define === 'function' && define.amd ? define(['exports'], factory) :
(factory((global.d3 = global.d3 || {})));
}(this, (function (exports) { ...
What does the library export preamble look like that you are using? How are you loading requirejs itself?
I am trying out the latest requirejs now to see if I also hit an issue.
UPDATE: so after digging into require.js I've found that while the code has the appearance of using the standard module pattern it misses the mark by never actually exporting to global. Instead the code creates lexically scope var requirejs;
which is not the same as exporting to global scope under strict mode. The good news is that requirejs does in fact load using ltng:require and if we get a trivial change to actually export global. require.js = requirejs;
this would work. I am making that change to requirejs locally to test this to completion. If that is successful I'll look at opening a pull request to https://github.com/requirejs/requirejs to get this fixed in the library.
UPDATE #2: got quite a bit farther and finally hit a Locker specific issue but we're very close. SecureScriptElement is not quite emulating a real script element in the area of onload events that requirejs chokes on (and rightly so). I'm opening a bug to track getting this fixed now.