Opened 9 years ago
Closed 9 years ago
#14510 closed defect (fixed)
[regression] "non-standard" modules attempt to load from wrong folder against standard build (same-domain)
Reported by: | Kenneth G. Franqueiro | Owned by: | Rawld Gill |
---|---|---|---|
Priority: | high | Milestone: | 1.7.2 |
Component: | Loader | Version: | 1.7.0 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
Given a simple module, test/module.js
, with the following code:
dojo.provide("test.module"); test.module = {"Hello": "World"};
... and a simple test page which attempts to load it, against a standard built release (i.e. non-src) of Dojo...
<!DOCTYPE html> <html> <body> <script src="dojo/dojo.js"></script> <script> dojo.require("test.module"); dojo.ready(function(){ console.log(test.module); }); </script> </body> </html>
... while this works against a 1.6 standard release build, it does not work against 1.7's; it attempts to load test/module.js
from underneath the dojo
directory.
While the examples above use the legacy APIs for ease of testing across versions, the same thing happens when using AMD against 1.7 with async: true
.
If you were to build the test
package into a profile (e.g. by specifying it in the prefixes
array), this test would work fine. It also works fine when running completely from Dojo source. It would seem that the configuration dumped into dojoConfig
in the built dojo.js
is somehow confusing the loader into loading "unknown" packages from underneath the dojo
folder.
I'm not sure whether this is something fixable, nor how common a use-case we consider standard release + custom modules (rather than full source across the board) to be, but at any rate it's something that worked in 1.6 and doesn't in 1.7.
Change History (3)
comment:1 Changed 9 years ago by
Status: | new → assigned |
---|
In [27768]: