Skip to content
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

Upgrading from 0.1.14 -> 0.2.4, global should be defined #15

Open
GCheung55 opened this issue Aug 27, 2014 · 6 comments
Open

Upgrading from 0.1.14 -> 0.2.4, global should be defined #15

GCheung55 opened this issue Aug 27, 2014 · 6 comments

Comments

@GCheung55
Copy link

Upgrading from 0.1.14 -> 0.2.4, global should be defined but an JS error is being thrown that "global is not defined".

@GCheung55
Copy link
Author

I think it's related to the change in https://github.com/requirejs/cajon/blob/master/tools/c.js#L41. Using global.eval vs eval.

When eval is used, global is provided via the scope chain, but global.eval doesn't.

@jrburke
Copy link
Member

jrburke commented Sep 7, 2014

If you have an example or test case that shows what kind of module loading breaks, that would help figure out a solution.

@GCheung55
Copy link
Author

Here's a CommonJS module to test global.

https://gist.github.com/GCheung55/5116931959a24afc1b2a

I just tried [email protected] and the issue is reproducible.

@jrburke
Copy link
Member

jrburke commented Oct 28, 2014

Looking more at this, while the behavior changed in #8, it was for correctness -- best not to leak the private variables inside the loader to the evaluated text, and to provide a consistent eval environment. So I would expect the behavior as typeof global being undefined.

Is this more about compatibility with modules from node? If so, that is a trickier issue. Node has other implied available variables, like process, but I was not planning on simulating a node environment with cajon, just providing an "unwrapped" modules in the style of CommonJS/Node. But just on the style of module APIs, not on their execution environment.

If this was needed, for a particular project, it can be provided outside the loader:

<script src="cajon.js"></script>
<script>
var global = this;
require(['app']);
</script>

Does that meet the goals?

@GCheung55
Copy link
Author

True, I could add var global = this;. I don't expect a complete simulation of a node environment. process doesn't make sense to simulate, especially since there isn't an equivalent in a browser environment. But I think a global equivalent in a browser environment would be window.

How do you feel about exposing global as an argument to the module's callback?

define(function(require, module, exports, global){})

I ask because this would be a tiny bit more performant than looking up the scope chain in order to find global set as a global variable.

@GCheung55
Copy link
Author

Also, there are node modules that are written for both browser and server environments. The one I'm currently using is https://github.com/kamicane/prime/blob/master/defer.js which makes use of checking global for properties/methods. It's treating global as window.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants