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

TypeError: Cannot read property 'length' of undefined #169

Closed
kamalt opened this issue Feb 29, 2016 · 24 comments · Fixed by #171
Closed

TypeError: Cannot read property 'length' of undefined #169

kamalt opened this issue Feb 29, 2016 · 24 comments · Fixed by #171

Comments

@kamalt
Copy link

kamalt commented Feb 29, 2016

Node version: 4.3.1
OS: Mac EL Captain (10.11.3)

Error is thrown while using grunt-nodemon which has a dependency with "es6-promise" package. Error details are given below,

TypeError: Cannot read property 'length' of undefined
at lib$es6$promise$$internal$$fulfill (/Users/kt/node_modules/grunt-nodemon/node_modules/nodemon/node_modules/es6-promise/dist/es6-promise.js:303:31)
at lib$es6$promise$$internal$$resolve (/Users/kt/node_modules/grunt-nodemon/node_modules/nodemon/node_modules/es6-promise/dist/es6-promise.js:285:9)
at lib$es6$promise$$internal$$invokeCallback (/Users/kt/node_modules/grunt-nodemon/node_modules/nodemon/node_modules/es6-promise/dist/es6-promise.js:396:9)
at /Users/kt/node_modules/grunt-nodemon/node_modules/nodemon/node_modules/es6-promise/dist/es6-promise.js:166:11
at lib$es6$promise$asap$$flush (/Users/kt/node_modules/grunt-nodemon/node_modules/nodemon/node_modules/es6-promise/dist/es6-promise.js:119:9)
at doNTCallback0 (node.js:419:9)
at process._tickDomainCallback (node.js:389:13)
at Function.Module.runMain (module.js:469:11)
at startup (node.js:136:18)
at node.js:963:3

@tdeekens
Copy link

Same issue on node 0.12.4 with the latest version. Let me know how I can help. Though it doesn't seem to be es6-promise itself. I'll dig into it and report...

@wen96
Copy link

wen96 commented Feb 29, 2016

Same issue on node 0.10.25. I guess could be related with karma-runner/karma#1946 not es6-promise.

@cyrilgandon
Copy link

@wen96 I confirm, same error

TypeError: Cannot read property 'length' of undefined
at lib$es6$promise$$internal$$fulfill (.\node_modules\grunt-ts\node_modules\csproj2ts\node_modules\es6-promise\dist\es6-promise.js:273:31)
at lib$es6$promise$$internal$$resolve (.\node_modules\grunt-ts\node_modules\csproj2ts\node_modules\es6-promise\dist\es6-promise.js:255:9)
at lib$es6$promise$$internal$$invokeCallback (.\node_modules\grunt-ts\node_modules\csproj2ts\node_modules\es6-promise\dist\es6-promise.js:366:9)
at .\node_modules\grunt-ts\node_modules\csproj2ts\node_modules\es6-promise\dist\es6-promise.js:891:13
at lib$es6$promise$asap$$flush (.\node_modules\grunt-ts\node_modules\csproj2ts\node_modules\es6-promise\dist\es6-promise.js:125:9) at doNTCallback0 (node.js:408:9)
at process._tickCallback (node.js:337:13)

@sinbads5
Copy link

I moved Karma up before Promise and it solved the issue

@oliversommer
Copy link

for me it's related to core-js which is a transitive dependency of karma. I pinned core-js at 2.1.1 and this way it worked for me.

@michaelbazos
Copy link

The issue is indeed related to _core-js 2.1.2_.

I was able to get rid of the error by adding an npm-shrinkwrap.json along with the package.json, so as to control the version of any package in the dependency tree (documentation):

_npm-shrinkwrap.json:_

{
  "name": "<your app name>",
  "dependencies": {
    "karma": {
      "version": "0.13.21",
      "dependencies": {
        "core-js": {
          "version": "2.1.1"
        }
      }
    }
  }
}

@zloirock
Copy link

It's a bug in es6-promise. In feature detection, core-js detected @@species constructor pattern support in Promise#then. es6-promise not supports it and throws an error. Feature detection wrapped in try / catch, but an error throws async.

Reproducible example:

require('es6-promise');
var p = Promise.resolve();
p.constructor = function(it){ it(function(){}, function(){})};
p.constructor[Symbol.species] = function(it){ it(function(){}, function(){})};

try {
  var f = p.then(function(){});
  console.log('works: ', f instanceof p.constructor[Symbol.species]);
} catch(e){
  console.log('caught error');
}

@bliitzkrieg
Copy link

+1

@stefanpenner
Copy link
Owner

@zloirock I can believe it is an issue with es6-promise, but as a note I think your reproduction is also in error.

I believe as an amendment @@species is no longer available as a static member, only as instance. So Promise.constructor[Symbol.species] will end up just getting ignored.

http://www.ecma-international.org/ecma-262/6.0/#sec-promise.all vs https://tc39.github.io/ecma262/#sec-promise.all

@zloirock
Copy link

@stefanpenner it's detection @@species in Promise#then

@stefanpenner
Copy link
Owner

@zloirock are you not placing it on p.constructor[Symbol.species] = function(it){ it(function(){}, function(){})};?

@zloirock
Copy link

@stefanpenner ?

@stefanpenner
Copy link
Owner

@zloirock sorry, my point was i don't believe p.constructor[Symbol.species] = <anything> has any impact after the latest amendment to the spec.

The latest iteration of the spec only checks for @@species on the instance (not constructor) compare latest vs original

@stefanpenner
Copy link
Owner

the bug described here is totally in es6-promise (one I have been intending to fix for some time, so no time like the present), although I do believe core-js's detection is also in-error.

@zloirock
Copy link

@stefanpenner
Copy link
Owner

@zloirock in the latest iteration of the spec i do not see any reference to constructor[@@species], if memory serves it was actually removed. And only per-instance @@species remains.

I believe the comment you provided a link to refers to the old behavior. It was realized that static @@species was added in error, and actually posses a pretty hefty hazard.

@zloirock
Copy link

@stefanpenner
Copy link
Owner

huh, then I think the spec concern wasn't addressed. Ignore me for now (conversations I remember, and spec do not seem to be in agreement)

@zloirock
Copy link

@stefanpenner
Copy link
Owner

Yes these discussion were side-channel, specifically awb and myself discussing this in person. I'll reach out and see if I merely misunderstood our conversation.

If memory serves the TL;DR was, @@species was not a static/class concern, rather an instance concern. Allowing it to inherit class side, ultimately means subclasses must defensively shadow get [Symbol.species]() { return this; }). Which is lame :P

Regardless its good that both these issues have been brought to light. I'll work to address both.

@stefanpenner stefanpenner mentioned this issue Feb 29, 2016
4 tasks
@dschaller
Copy link

+1. Pinning Karma to 0.13.19 seems to work for me

@stefanpenner
Copy link
Owner

I am most likely going to provide a quick-fix targeting this exact issue shortly, and then circle back with a proper fix later.

@sjungling
Copy link

+1 for pinning karma to 0.13.19 AND core-js to 2.1.1. Tried just pinning karma alone and that didn't work with our env but the combo of both of them seems to get Jenkins happy for us.

@stefanpenner
Copy link
Owner

Merged + released an interim solution, will address the larger subclass + constructor tampering problem next.

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 a pull request may close this issue.