Opened 8 years ago

Closed 8 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 8 years ago by Rawld Gill

Status: newassigned

comment:2 Changed 8 years ago by Rawld Gill

In [27768]:

added default has switch value to make top-level modules siblings of dojo; refs #14510; !strict

comment:3 Changed 8 years ago by Rawld Gill

Resolution: fixed
Status: assignedclosed

In [27796]:

backport [27768], fixes #14510; !strict

Note: See TracTickets for help on using tickets.