-
Notifications
You must be signed in to change notification settings - Fork 339
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
Globals and exports #3
Comments
Hi, there is no reason for this except that I don't know how it should be done properly. If you can fix this with a PR I'd be happy to merge |
is this a big change? I'm not exactly sure what's involved. And is this done so that things work transparently on both node and browser? Or what's wrong with the current way? It does create two new globals R and RL that hold the lib. |
Looks like that check pattern you included on the ConvnetJS which dumps it into
I believe that check takes care of all the cases. Anything which would require Now what is wrong with the current way..... Maybe nothing.... You're keeping everything simple and flat without package managers, maybe the best bet is a separate wrapper which can be used with node, which simply does the checks and throws everything in exports regardless. |
I've wrapped it using this pattern, once execfile.js
foo.js
|
Would something like this be an option? |
Yeah similar to this: https://github.com/karpathy/convnetjs/blob/master/src/convnet_export.js Think in the end it's probably not really needed, depends on if this lib is about being a block of code in one file, simple and with much of the bones showing... or a package for people to install and run with. |
Any reason for deciding to go with globals over checking for browser and delivering
window.RL
ormodule.exports.RL
?Something you'd accept as a PR, if it was done in a way that fits?
The text was updated successfully, but these errors were encountered: