Skip to content

in the AMD case, reveal the global right away #288

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

Merged
merged 1 commit into from
Dec 3, 2014

Conversation

mwcz
Copy link
Contributor

@mwcz mwcz commented Nov 11, 2014

This is to accomodate synchronous code that might be running alongside AMD modules. The AMD case already exposes the window.Raven global, however previous to this patch it waited until the AMD module was specified as a dependency before initializing the global.

I figure that if the global is going to be exposed in the AMD case, it
may as well happen right away, so non-AMD code can depend on it being
there. :)

This is to accomodate synchronous code that might be running alongside
AMD modules.  The AMD case already exposes the window.Raven global,
however previous to this patch it waited until the AMD module was
specified as a dependency before initializing the global.
@mattrobenolt
Copy link
Contributor

lol Jesus.

Serious question here because I don't work in this space: why isn't there just a copy/paste thing that every library does? We've gone back and forth on this like, 10 times now.

@mwcz
Copy link
Contributor Author

mwcz commented Nov 12, 2014

Sorry, I didn't know the history! Here's my take on this specific issue:

If someone's code is entirely in AMD format, they'll never need the window.Raven global. Contrarily, if none of their code is AMD, they'll get the global.

But in the project I work on, some code is AMD, and some isn't, so it makes sense (for me) to expose the global and register the AMD module. Raven's already doing that, cha-ching, except it doesn't expose the global until the AMD module has been requested with a require(['raven']) call. If the global is going to be exposed so that synchronous code can use it, it shouldn't be reliant on asynch code to establish the global.

If you'd like to use jQuery as an example, they register an AMD module and expose a global separately.

I wish there was just One Right Way too... I guess it's because JS has never had a module system, so people invented them (hence "14 competing standards" syndrome). That legacy of suckage has a cost. You've gotta accomodate a wide variety of historical abuses and competing module standards if you want to appeal to the widest audience. ES6 introduces a real module system, but the older module system's aren't going to vanish overnight. Can you imagine if Python had four different types of import?

if pmd:
    pmd.load(mymodule)
elif pypack:
    ppyack.include(mymodule)
elif require:
    require.once(mymodule)
else:
    import mymodule

lol indeed

@mattrobenolt
Copy link
Contributor

I agree with this to not break backwards compatibility.

mattrobenolt added a commit that referenced this pull request Dec 3, 2014
in the AMD case, reveal the global right away
@mattrobenolt mattrobenolt merged commit bdf400c into getsentry:master Dec 3, 2014
@mwcz mwcz deleted the reveal-global-when-amd branch December 4, 2014 14:55
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

Successfully merging this pull request may close these issues.

2 participants