Skip to content

global export #14

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

Closed
jasonkarns opened this issue Nov 14, 2016 · 5 comments
Closed

global export #14

jasonkarns opened this issue Nov 14, 2016 · 5 comments

Comments

@jasonkarns
Copy link
Contributor

jasonkarns commented Nov 14, 2016

I see that the SDK compiles a browser distributable via webpack. However, I don't see what the globally exported variable name is for the distributable. Unfortunately none of the docs show usage other than require(... which isn't helpful.

More specifically, if webpack's configuration option output.library were set explicitly, this variable name would be abundantly clear.

@mikeproeng37
Copy link
Contributor

Thanks for bringing this up @jasonkarns. I've created an item on our backlog to address this for the next release.

@jasonkarns
Copy link
Contributor Author

Cool! In the interim, could you share exactly what the exported variable name actually is?

@mikeproeng37
Copy link
Contributor

We actually aren't exporting it globally. This is something we missed in our implementation, sorry! The only way to use it currently would be via CommonJS. We'll be working on exposing a global variable soon.

@jasonkarns
Copy link
Contributor Author

How is that possible? Webpack defaults to exporting via global variable if output.libraryTarget isn't specified (it defaults to var). https://webpack.github.io/docs/configuration.html#output-librarytarget

And your current webpack config clearly does not set libraryTarget:

output: {
filename: 'optimizely.min.js',
path: './dist'
},

@mikeproeng37
Copy link
Contributor

I believe because we do not have the output.library option defined it is not exporting anything globally at all.

I have a PR open for this: #18
Just waiting for our tests to pass in order to release it

mjc1283 added a commit that referenced this issue Apr 22, 2019
…lable' (#14)

Summary:

This changes the behavior of the `onReady` Promise to align with the Java implementation. The `onReady` Promise is now resolved as soon as the datafile manager has any datafile (whether it was passed in or fetched). An update event is always emitted when the datafile changes after `onReady`.

Test plan:

Updated unit tests
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