stripe / stripe-node

Node.js library for the Stripe API.
https://stripe.com
MIT License
3.87k stars 748 forks source link

TypeError: Cannot read property 'prototype' of undefined at runInContext #211

Closed Aishwarya-K closed 8 years ago

Aishwarya-K commented 8 years ago

I am integrating Stripe Api . While i run the code with correct api key I am getting error

TypeError: Cannot read property 'prototype' of undefined at runInContext on (../node_modules/stripe/node_modules/lodash/index.js 718:27)

After some research, I have found a solution by adding
if (typeof context.Object !== 'function') context = this; Then, another error is generated.

An error occurred : Cannot read property 'call' of undefined

My current version of nodejs is v4.2.1. The Api key is correct, I am not sure what the problem is. Does anyone have any ideas?

remi-stripe commented 8 years ago

Hey @Aishwarya-K, Does this happen as soon as you set your API key or on some specific code? Is there any chance you could share the code you're currently using so that I can attempt to reproduce the issue?

Also, what is your current API version in your account? You can find this in your account settings here: https://dashboard.stripe.com/account/apikeys

Also, which version of the node.js library are you using right now?

Aishwarya-K commented 8 years ago

Hi @remistr My current version of Api accout is 2015-10-16 (latest). My current version of nodejs is v4.2.1.

var stripe = require('stripe')('sk_test_**********************i');
        stripe.charges.create({
        amount: 1600,
        currency: 'usd',
    }, function(err, charge) {
        if (err) {
           console.log(err);
        } else {
             console.log(charge);
        }
    });
    res.end();
 });

Payment is carried out succesfully after fixing the protype error. But i didnt receive the response. Instead receive

An error occurred : Cannot read property 'call' of undefined

remi-stripe commented 8 years ago

That code wouldn't work as you're not providing a customer id or a source it in the parameters list. Are you sure this is the exact code that causes an issue? Do you have an issue with any other function you call? Also, which version of our Node.js bindings are you currently on?

Aishwarya-K commented 8 years ago

Yes i am sure that i am using same code. Eventhough if customer.id is not given ,it throws error related to the missing customer id field. Right? I am receving the same error while I use Authorize.net. Both have Lodash.js and Bluebird library. Is there any chances of any conflict between modules. I am using version 2.

matthewarkin commented 8 years ago

@Aishwarya-K can you share the output of npm ls or your package.json (assuming you have it with all your packages).

Npm 2 would not have caused dependency issues, but Npm 3 has changed how they deal with it a bit

Aishwarya-K commented 8 years ago

This is my pacakge.json

{
  "name": "******hidden***********",
  "version": "2.0.0",
  "description": "******hidden************",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "******hidden************",
  "license": "ISC",
  "dependencies": {
    "async": "^0.9.0",
    "auth-net-cim": "^2.1.0",
    "auth-net-types": "^1.1.0",
    "body-parser": "^1.9.3",
    "braintree": "^1.23.0",
    "busboy": "^0.2.9",
    "coffee-script": "^1.8.0",
    "connect-busboy": "0.0.2",
    "cookie-parser": "^1.3.3",
    "crypto": "0.0.3",
    "customer.io": "0.0.2",
    "date-util": "^1.2.1",
    "date-utils": "^1.2.16",
    "dateformat": "^1.0.11",
    "error": "^4.3.0",
    "express": "^4.10.4",
    "express-csv": "^0.6.0",
    "express-domain-middleware": "^0.1.0",
    "forever": "^0.13.0",
    "forever-monitor": "^1.5.2",
    "form-data": "^0.1.4",
    "fs": "0.0.2",
    "implode": "^2.0.1",
    "ini": "^1.3.2",
    "middleware": "^1.0.0",
    "moment": "^2.9.0",
    "morgan": "^1.5.0",
    "multer": "^0.1.6",
    "mysql": "^2.5.3",
    "node-customer.io": "0.0.2",
    "node-linkedin": "^0.3.4",
    "nsmarty": "0.0.1",
    "passport": "^0.2.1",
    "passport-facebook": "^1.0.3",
    "passport-linkedin-oauth2": "^1.2.1",
    "passport-twitter": "^1.0.2",
    "paypal-ipn": "^3.0.0",
    "q": "^1.1.2",
    "qs": "^2.3.3",
    "querystring": "^0.2.0",
    "recaptcha": "^1.2.0",
    "reload": "^0.1.0",
    "routes": "^2.0.0",
    "session": "^0.1.0",
    "socket.io": "^1.2.1",
    "sort": "0.0.3",
    "sorted-array": "^1.1.1",
    "split_er": "^1.2.0",
    "stripe-api": "^0.1.2",
    "util": "^0.10.3",
    "wait.for": "^0.6.6",
    "xml-writer": "^1.6.0"
  },
  "devDependencies": {}
}
brandur commented 8 years ago

Hi @Aishwarya-K, sorry about the trouble!

I haven't written enough Node to have a good intuitive sense of what the problem might be here, but if anyone else does, let us know! This one's also a bit tricky in that it doesn't seem to be too widespread (not necessarily true of course, but so far you're the only one to report it).

Is there any chance that you could try to put together a minimal reproduction suite? That would be really helpful in allowing us to debug and resolve the issue. Let us know, thanks!

matthewarkin commented 8 years ago

Hmm, I ended up having one of these similar issues in another project, somehow my node-modules got corrupted. Have you tried deleting your node-modules and rerunning npm install?

Aishwarya-K commented 8 years ago

hi @matthewarkin , @brandur ,

I somehow fixed the issue by using stripe-api module which does not have lodash and bluebird. In my module list, I have a module which have lodash and bluebird. It is working perfect. There was no corruption coz all other modules are working fine. And Stripe module is installed without any errors. I have a simlar error with the Authorize module too.. I think this may be the conflict issues with lodash and bluebird.

brandur commented 8 years ago

@Aishwarya-K Thanks for the additional info!

Alright, this doesn't sound directly related to the Stripe library, so I'm going to close it out. I'm still a little confused as to the actual cause, but at least it should give us a data point on possible misbehaving libraries should the issue appear again.

@matthewarkin Thanks for following up! If you have any other ideas on what the deeper cause here might've been, let me know :)