TypeError: Cannot read property 'length' of undefined

[kamalt]

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]

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]

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

[cyrilgandon]

@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]

I moved Karma up before Promise and it solved the issue

[oliversommer]

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]

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]

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]

+1

[stefanpenner]

@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]

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

[stefanpenner]

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

[zloirock]

@stefanpenner ?

[stefanpenner]

@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]

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]

@stefanpenner zloirock/core-js@0a144de#commitcomment-16290552

[stefanpenner]

@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]

@stefanpenner https://tc39.github.io/ecma262/#sec-speciesconstructor

[stefanpenner]

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]

Nothing about removing this.constructor[@@species], just removing @@species from statics - https://gist.github.com/allenwb/8c50729c4c1c158fa8eb https://github.com/rwaldron/tc39-notes/blob/master/es7/2015-11/nov-18.md#improving-consistency-of-species-kevin-smith

[stefanpenner]

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.

[dschaller]

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

[stefanpenner]

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]

+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]

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