Load Order Issues

[kbaltrinic]

I am trying to use Squire to help bring test coverage to a fairly complicated application (200+ coffeescript files) and am running into some timing depended load issues. I have managed to create a simple example app that sometimes demonstrates the problem.

The problem is simply this. We are using jQuery and a jQuery plugin called BlockUI, that later is in turn used in a several views. All is fine in normal usage, but when we use Squire to load the view for testing, jQuery and BlockUI both get loaded twice (once on the default context, once in "context0"). This is because we have two specs. One that uses squire and one that does not.

If everything goes well (about 80% of the time on my machine) the load order is jQuery in the default context, BlockUI in the default context, jQuery in context0, blockUI in context0. The rest of the time, both jQuery instances load first, followed by both BlockUI instances. This causes both BlockUI instances to plug into the second jQuery instance. Consequently the tests that try to use BlockUI on the first instance blow up as $.blockUI is undefined in that case.

I can reproduce this issue in both Chrome and Firefox, but would expect to see it in any browser.

In the aforementioned example app, just run the ./test.sh script. Then in the browser, turn off caching and hit refresh several times till the problem appears (as a failing test).

In the example I have inserted logging code into both jQuery and BlockUI to track instances identity and log what is going on. A good log looks like this:

JQuery init: 1
JQuery.blockUI init: 2 with jQuery: 1
JQuery init: 3
JQuery.blockUI init: 4 with jQuery: 3

A log showing the issue looks like this:

JQuery init: 1 
JQuery init: 2
JQuery.blockUI init: 3 with jQuery: 2
JQuery.blockUI init: 4 with jQuery: 2

AssertionError: $.blockUI was undefined in example-view: expected undefined to not equal undefined
    at Assertion.assertEqual (http://localhost:7357/4673/.mimosa/testemRequire/chai.js:862:12)
    at Assertion.ctx.(anonymous function) [as equal] (http://localhost:7357/4673/.mimosa/testemRequire/chai.js:3048:25)
    at Function.assert.isDefined (http://localhost:7357/4673/.mimosa/testemRequire/chai.js:2073:36)
    at Context.<anonymous> (http://localhost:7357/js/app/example-squire-spec.js:13:23)
    at Test.Runnable.run (http://localhost:7357/4673/.mimosa/testemRequire/mocha.js:3726:32)
    at Runner.runTest (http://localhost:7357/4673/.mimosa/testemRequire/mocha.js:4081:10)
    at http://localhost:7357/4673/.mimosa/testemRequire/mocha.js:4127:12
    at next (http://localhost:7357/4673/.mimosa/testemRequire/mocha.js:4007:14)
    at http://localhost:7357/4673/.mimosa/testemRequire/mocha.js:4016:7
    at next (http://localhost:7357/4673/.mimosa/testemRequire/mocha.js:3964:23)

It seems to me that a solution to this would be to be able to configure Squire with a list of assets that should never be reloaded but rather should be shared across contexts. It should then be an error to ever specify one of those assets' identifiers to .mock().

[kbaltrinic]

I have come up with a workaround that involves requiring a reference to jQuery in the spec and then telling Squire to mock jquery using that reference. This keeps jQuery from loading twice. Its a hacky but it works for now.

NB: I may be using this require-example repo to test out some other things as well so instead of looking master for this issue look at the squire-issue-39 branch, which shows the problem, and the squire-issue-39-workaround branch which demonstrates this workaround.

With the workaround in place the log now looks like this:

JQuery init: 1 
JQuery.blockUI init: 2 with jQuery: 1 
JQuery.blockUI init: 3 with jQuery: 1 

[kbaltrinic]

A further workaround gets me down to:

JQuery init: 1 
JQuery.blockUI init: 2 with jQuery: 1 

[marcins]

Old issue but I ran into a similar issue where Squire would try to load jquery, seemingly ignoring the shim (jquery is provided through another module in our environment). Mocking jquery to the existing jquery as you suggested stopped the error, but I'd be interested in finding out the root cause.

I previously ran into other issues where modules required outside the injector and inside the injector would sometimes not reference the same module, it's probably related (not just jquery).