-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AMD dependencies on cjs/shimmed modules cause 'Module not already loaded loading "process" from "undefined"' error. #942
Comments
What module is loading |
You're right to wonder that, because as far as I can tell, neither velocity.js nor velocity.ui.js use process. However, when I do the following, and look into the velocity source that gets downloaded, both modules are wrapped in To reproduce, only the following is necessary (I've done this a several times to be sure):
from meta: {
"velocity": {
"format": "cjs"
},
"velocity/velocity": {
"format": "cjs"
},
"velocity/velocity.ui": {
"format": "amd",
"deps": ["velocity"]
}
},
<html>
<head>
<script src="/jspm_packages/system.js"></script>
<script src="/config.js"></script>
<script>
window.require = System.amdRequire;
window.define = System.amdDefine;
System.import('velocity/velocity.ui').then(function (Velocity) {
console.log('imported velocity.ui');
});
</script>
</head>
<body>
Hi there!
</body>
</html> |
Could this have something to do with In case you are astute, you might notice that the velocity.js and velocity.ui.js files I linked to above are version 1.2.3, and I was installing 1.2.2: I checked this doesn't make a difference. And performing a fresh install without the registry option doesn't prevent the wrapping either. Am I misunderstanding something? |
Yes exactly, when installing from npm, we treat all modules as CommonJS, which involves adding the process dependency as a CommonJS wrapper if the If you then alter the format to AMD, the |
Thanks for the response. I am using
I had enough of these issues that I upgraded Marionette and a number of other libraries (a good thing to do, but takes time and effort), and avoid using the bower endpoint anytime there's a choice. In general, I'm installing npm packages because it seems like the alternative is github, and using github currently requires me to keep track of the third party's dependencies; adding them to my Just checking, sorry if it seems repetitive: when I use Please correct me if I am misunderstanding: the jspm registry currently just delegates to a registry preferred for the given package. So if the default jspm registry entry maps to npm (as it does sometimes: for simple example: On the topic of this error message: velocity has only a dependency on jquery. jQuery has no dependencies. I said
And it certainly didn't yesterday. Today I've reinstalled the global jspm, and have made sure to install a local copy into each project. Now, when I create a fresh project, it seems that Velocity is no longer wrapped (phew). This is a mystery to me. I noticed that Correct me if I'm wrong: Only explicit dependencies of a package installed with jspm are candidates for wrapping that package. If So velocity should never have been wrapped for Intelligent handling of global libraries is actually a gigantic issue that I need a solution for. Experimentally, I found out SystemJS loads global libraries globally. So, do npm dependencies need to be wrapped for Node and that's the reason and only reason for the wrapping? Apologies, because relatively, I am a newcomer to the javascript toolchain. This last part should nearly certainly be a separate question,but it's tangentially related: For global libraries, SystemJS doesn't provide any way to "un-global" it, does it? I can't think of a foolproof way this could ever be done (but it would be amazing and fix everything in the universe: that is, to prevent libraries from writing to the real Barring the ability to encapsulate, how does SystemJS create System.delete(System.normalizeSync('highcharts-v1'));
delete window['Highcharts'] && delete window['HighchartsAdapter']; But, if I want it back, |
Yes exactly. The I was actually just working this past week on the upcoming jspm 0.17 implementation of this conversion process, so that we don't do these types of wrappings for other module formats and avoid these issues by first doing a full module format detection for every module before handling the conversion. At the moment SystemJS could in theory stop globals from writing to the global. SystemJS carefully controls the globals available to global scripts so that multi version globals are supported. We do this by managing the globals on the window object before the execution of each global. But the edge case is non synchronous reads to We could potentially enable this full encapsulation quite easily with a flag. I've created #960 which would solve your Highcharts issue I believe. |
I've created a simplified project that only imports velocity.ui (which supports use as an amd, cjs, or global module and is distributed with velocity). Velocity itself is a jQuery shim -- I'm marking it as a cjs module. Adding the following to my config.js file allows velocity.ui to be imported with its dependency on velocity resolved (but...):
meta: { "velocity": { "format": "cjs" }, "velocity/velocity": { "format": "cjs" }, "velocity/velocity.ui": { "format": "cjs", "deps": ["velocity"] } },
But, if I instead use
...
"velocity/velocity.ui": { "format": "amd",
...
I get 'Uncaught Error: Module not already loaded loading "process" from "undefined".'
It seems to me that this should work, given that velocity.ui ostensibly supports amd loading. This problem has recurred a couple times in migration of ~12,000 lines of js from requirejs to systemjs, so I'm hoping to get this resolved: I have some homebrewed amd modules whose cjs/shim dependencies aren't being resolved. (If I change
define
torequire
in the amd files, some of the error messages go away, which also confuses me.) I've attached the simplified project (as text files, sorry).config.txt
index.txt
package.txt
The text was updated successfully, but these errors were encountered: