ember-concurrency: waitForProperty is undefined?

Using ember-concurrency 0.8.15 (latest)

import { task, waitForProperty } from 'ember-concurrency';


	_validityChanged: task(function*() {
		while (true) {
			yield waitForProperty(this, "validations.isValid", value => true);
			this._publishValidity();
		}
	}).on('init'),

Error:

rsvp.js:27 Uncaught TypeError: (0 , _emberConcurrency.waitForProperty) is not a function
    at Class.<anonymous> (validated-component.js:27)
    at Generator.next (<anonymous>)
    at Class._resumeGenerator (-task-instance.js:431)
    at Class._handleResolvedContinueValue (-task-instance.js:586)
    at Class._proceed (-task-instance.js:550)
    at Class._scheduleProceed (-task-instance.js:538)
    at Class._start (-task-instance.js:242)
    at Class._startTaskInstance (-scheduler.js:104)
    at Class._flushQueues (-scheduler.js:80)
    at Class.schedule (-scheduler.js:62)

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 1
Comments: 17 (14 by maintainers)

Most upvoted comments

@BryanCrotaz i believe that idea is on the cli team’s agenda

machty on Feb 28, 2018

side note: ember-cli-dependency-lint can be helpful in flagging this sort of risk

lukemelia on Feb 28, 2018

TL;DR yarn doesn’t aggressively dedupe your project’s dependencies, and other dependencies’ dependencies get checked into yarn.lock, and ember-cli merges ALL of the detected e-c versions to the broccoli tree in a non deterministic order, so there’s no guarantee which version of e-c you’re importing into your app. The solution is to yarn upgrade every dependency that might be using e-c, or to nuke your node_modules and yarn.lock and do yarn install.

I’m sure there’s plenty more discussions to be had regarding this ember-cli behavior but this does not appear to be an ember-concurrency-specific bug.

machty on Feb 27, 2018

Wow that’s super gross 😦

machty on Feb 26, 2018