Ember router doesn't know that it's without router.router while testing.

[nathanhammond]

This line interacts very oddly in our 1.13 (release channel edge) testing:
https://github.com/emberjs/ember.js/blob/master/packages/ember-routing-views/lib/views/link.js#L269

The get call fails with the obj in that call being undefined (nonsensically, it's clearly being passed in). However, if I change it to:

var routing = get(this, "_routing") || this._routing;

... then it works. This seems counter to failure modes I'm familiar with in Ember. Error message is (since routing isn't set for the subsequent get call): "Assertion Failed: Cannot call get with 'targetState' on an undefined object."

(Posting this primarily for search engines.)

[nathanhammond]

Here's the minimalist reproduction. I'll be tracing this tomorrow.

Notes:

1. Yes, that syntax is incorrect for the {{link-to}} helper, however, I don't believe that should cause it to fail in this way. (This appears to matter when it's a helper in my more-complicated scenario.)
2. Fixing that syntax ({{#link-to "index"}}index{{/link-to}}) simply creates a second error: "Cannot read property 'generateURL' of undefined"

Something fishy here.

[nathanhammond]

Original report is a collection of symptoms from just one problem. The issue is simply this: the container set up for testing doesn't resolve for service:-router. This means that the router becomes undefined and results in different failures depending upon where you were when you tried to do something with your reference to the router.

Haven't decided how best to fix this, just documenting.

[rwjblue]

@nathanhammond - these lines ensure that the default built registry contains service:-routing, and emberjs/ember-test-helpers#49 (which is incorporated into [email protected]) ensures that the registry contains all of these default items. Are you using [email protected]?

[nathanhammond]

Still an error moving to [email protected], just a different one. :) I've updated all dependencies to their latest versions in the minimal reproduction.

emberRouter.router is undefined here.

Untraced at this point, will continue to look...

[nathanhammond]

Two issues:

• [BUGFIX beta] {{link-to}} before application boot #11522 never made it into the 1.13 branch. Compare master to stable. @rwjblue I don't know the build magic to fix that or if I should just submit an identical PR to the stable branch.
• We need to add router.setupRouter(); here.

[nathanhammond]

Open cherry-picked PR.

[rwjblue]

#11522 was not targeted for release branch, and we do not want to start routing for integration tests. With the latest beta builds, you should be able to use a {{link-to}} in your ember-qunit integration tests without calling 'startRouting'.

[nathanhammond]

The answer here can't be "don't use 1.13" or "move directly from 1.12 to 2.0." If 1.13 is going to actually receive first class support for the long term (and is our bridge for deprecations), we need testing of components with {{link-to}} in them to actually work. As it stands we still don't have a story for that.

I'm game to code up other solutions, this was the minimally-invasive approach. Proposals?

(We can consolidate conversation here for all of these things.)

/cc @tomdale because of #11522

[rwjblue]

As I commented in that other PR, we need to vet the changes from #11522 to make sure they do not make matters worse in 1.13.

[nathanhammond]

Okay, and calling setupRouter (clarification: not startRouting) isn't kosher inside of ember-test-helpers? I'm doing that primarily to build router.js so that API surface is available (and router.router isn't undefined). Is there a better solution? Just landing #11522 doesn't fix everything.

[nathanhammond]

Offline conversation summary:

• Acceptance test with a generic {{link-to}} inside a component.
• Guard router.router instead of running setupRouter.
• And more...

[rwjblue]

Discussed a 'safe' solution (essentially adding a few more guards where we attempt to access 'router.router') with Nathan a few minutes ago. I think we can land those fixes into all branches (along with Tom's fix).

[tomdale]

While it isn't elegant, I'm OK with a pragmatic approach to returning compatibility to the 1.13 series. I'd like to revisit this entire code path in 2.x.

[nathanhammond]

Closed by #11639.