Template interning breaking compiled dijit .js with "value: ", only when nested prefix is used?

[Nick Fenwick]

This report was posted on the dojo-interest mailing list and wildbill advised I make a ticket.

I'm finding template parameters are broken when inlined into the .js file. This is not a problem for compiled layers containing the dijit, only the compiled .js dijit in the build output. Say I have ${thevariable} in my template, this is expanded to ${value: "duplicate template here", thevariable} .. yes, the entire template is copied in, including surrounding quotes, which makes the .js file it's inlined into invalid.

This is done in buildUtil.js buildUtil.interningRegexpMagic() function, by the lines:

endContent = endContent.substring(0, braceIndex + 1)
    + 'value: ' + jsEscapedContent + ','
    + endContent.substring(braceIndex + 1, endContent.length);

I cannot yet figure out what this code is supposed to do, however, I can avoid this breakage by rearranging my directory structure.

I've a slightly unusual prefix arrangement, because of my project's file structure. I build dijits for a number of deployment scenarios, and arrange my files like this:

resources/custom/scenario1/TheDijit.js
resources/custom/scenario1/templates/TheDijit.html
resources/custom/scenario2/TheDijit.js
resources/custom/scenario2/templates/TheDijit.html
resources/dojo/..the dojo sdk here..

In a build profile.js file for scenario1, I have:

prefixes: [
    [ "custom.scenario1", "../../custom/scenario1" ]

Is this valid?

This successfully pulls custom/scenario1 (and not other scenarios) into the build, and compiles it mostly OK, but the release/dojo/custom/scenario1/TheDijit.js compiled file contains the broken template intern described above.

Why is the lining process different for this nested prefix?

I nest my directories because of some third party dependencies in css. I am reevaluating my need to do this, but the arrangement is quite hard to change right now.

If I rearrange my directories so the prefix isn't nested, i.e.:

prefixes: [
    [ "custom, "../../custom" ]

Then TheDijit?.js is inlined correctly with no errors.

You can recreate the build I describe above by using the attached tarball. It contains the following files:

[neek testbuildcleandojo]$ tar tf /tmp/thedijittestbuild.tar
custom/scenario1/TheDijit.js
custom/scenario1/templates/TheDijit.html
dojo/util/buildscripts/profiles/testbuild.profile.js

Put a dojo sdk in ./dojo, with that profile file inside it, and run a build:

[neek testbuildcleandojo]$ cd dojo/util/buildscripts/
[neek testbuildcleandojo]$ ./build.sh action=clean,release profileFile=profiles/testbuild.profile.js releaseName=testbuild optimize=none cssOptimize=none layerOptimize=none copyTests=false mini=true log=0 2>&1 | tee out

You should find the ../../release/testbuild/custom/scneario1/TheDijit.js contains a broken templateString:

templateString: dojo.cache("custom", "scenario1/templates/TheDijit.html", "<div>\n\t<p>This is a simple ${value: "<div>\n\t<p>This is a simple ${variable}.  Wasn't that fun?</p>\n</div>\n",variable}.  Wasn't that fun?</p>\n</div>\n")

[Nick Fenwick]

tarball of example dijit and build profile as described in original bug description.

[Rawld Gill]

The function interningRegexpMagic is from the 1.6- builder so I'm not sure what you were running against 1.6 or 1.7.

I took your tarball and arranged it to exercise the test case (thank you for providing) by upgrading the profile to a v1.7 profile and ran against trunk [26705]. Everything worked correctly. I've attached the upgraded profile: install the test1 tree in the zip file as a sibling of dojo, dijit, and dojox directories. To see it build, make util/buildscripts the current working directory and issue the command

./build.sh --profile ../../test1/testbuild.profile.js --internStrings true --release