#15604 closed defect (fixed)
[regression] packageMap doesn't work with modules built into dojo/dojo
Reported by: | ben hockey | Owned by: | Rawld Gill |
---|---|---|---|
Priority: | blocker | Milestone: | 1.8 |
Component: | Loader | Version: | 1.8.0b1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
consider this part 2 of #15535 - it used to work (1.7.2) but now it doesn't.
in trunk, modules built into dojo/dojo don't load properly when packageMap
is in play.
the attached files are arranged similar to #15535 and the contents are only changed slightly:
rootDir/
pkg/
layer.js - some code with an i18n dependency
pkg.profile.js - build profile
plain.html - loads pkg/layer without using a packageMap config
packageMap.html - loads pkg/layer using a packageMap config
the key difference is that in the profile, "pkg/layer"
is now included in "dojo/dojo"
layers: { "dojo/dojo": { include: [ "dojo/i18n", "pkg/layer" ], boot: true, customBase: true } },
Attachments (4)
Change History (10)
Changed 9 years ago by
Changed 9 years ago by
Attachment: | pkg.profile.js added |
---|
Changed 9 years ago by
Attachment: | plain.html added |
---|
Changed 9 years ago by
Attachment: | packageMap.html added |
---|
comment:1 Changed 9 years ago by
Priority: | undecided → blocker |
---|
comment:2 Changed 9 years ago by
Description: | modified (diff) |
---|
comment:3 Changed 9 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:4 Changed 9 years ago by
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
this has regressed after r29249
comment:5 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
This seems to work after [29257] so long as localeList:0
is added to the build profile and
{ name:"dojo", location:"dojo" }
is added to the package config.
comment:6 Changed 9 years ago by
Milestone: | tbd → 1.8 |
---|
This is a very interesting special case. Looking at the last few lines of the built dojo/dojo.js, you'll see this:
When the cache gets consumed, the *now function is executed, which effectively executes
...which causes lots of dojo modules to be loaded. So, in spite of the line...
the dependency tree for dojo/i18n! gets loaded...which is essentially dojo base.
The next interesting thing that happens consequent to the i18n preload is attempting to load the flattened dojo/nls/dojo bundle for the current locale. E.g., on a en-us machine this results in loading the module dojo/nls/dojo_en-us. But, looking at the configuration provided in packageMap.html, we see an explicit baseUrl ("release") and no package config for the dojo package. This results in resolving dojo/nls/dojo_en-us to the url "./release/nls/dojo_en-us.js" which is incorrect and a 404 error results.
There are several ways to make this work:
For my taste, the best solution is to simply eliminate the preload algorithm by adding the build switch
to the profile. Since preloads are not being used, those code paths can optionally be trimmed from the build output by adding the static has values:
Building with no further changes results in a clean load. Notice the output of the network panel results in three requests:(1) packageMap.html, dojo/dojo.js, and dojo/cldr/nls/en/number.js. This is exactly as efficient as the preload algorithm....and a lot less complex.
In general, I do not believe the preload algorithm is valuable in the great majority of the cases. It was implemented in the 1.x branch because several customers were unable to change directions. I hope to remove it completely in 2.0.
The second way to fix the problem is to simply add a dojo config to packageMap.html like this:
With no other changes, the program loads, but at the expensive of loading the possibly-useless dojo base module tree.
The third way to fix the problem is to hack the built dojo/dojo.js to remove the preload at the bottom of the file.