[BUGFIX release] fix router test regression in urlFor and recognize #19733
Conversation
As part of the improvements made between 3.24 and 3.28, the router microlib is now lazily loaded. When these changes were made, there were a couple cases where it *should* be possible to access router state in a non-application test (integration etc.) but it currently is not because the router is not necessarily set up. Since `setupRouter` is idempotent, call it in those functions so that if it is *not* set up, it gets set up, and otherwise it will continue working as expected.
|
should this apply to |
|
@chriskrycho I remember working a bit on #19405 (In fact, I were clumpsy, because I made a similar PR on my own side). The setupRouter() thing, before, was here, https://github.com/emberjs/ember.js/pull/19405/files#diff-bdcd334bfbf30baf672240b941910d9462e59b46fb9091402ee107f214c40045L76, and I think it would be a good move to put that setup at that place again. So that accessing the router the first time, ensure it is set up. In my Pr #19454 I did'nt remove the setupRouter thing, and all tests were green |
|
@sly7-7 I only just saw this, sorry—I don't have any particular attachment to the way I implemented this, so if you've got a better one, landing it seems great! |
|
@NullVoxPopuli I don't know off the top of my head! |
As part of the improvements made between 3.24 and 3.28, the router microlib is now lazily loaded. When these changes were made, there were a couple cases where it should be possible to access router state in a non-application test (integration etc.) but it currently is not because the router is not necessarily set up. Since
setupRouteris idempotent, call it in those functions so that if it is not set up, it gets set up, and otherwise it will continue working as expected.Besides the change to the tests here, I have verified that this restores the previous behavior in our app.
Related to #19494. (Not marking as "fixes" because I'm not sure this covers 100% of that!)