Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#14133 closed defect (fixed)

source in custom namespaces work against dojo 1.7.0rc2 src but not against built

Reported by: Kenneth G. Franqueiro Owned by: Rawld Gill
Priority: high Milestone: 1.7
Component: Loader Version: 1.7.0b1
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by Kenneth G. Franqueiro)

I have the following directory structure:

  • dojo
  • dijit
  • dojox
  • mypackage

...where mypackage contains source code of modules written entirely in AMD style. The test pages in my package load dojo.js with async:true in dojoConfig, and proceed to use require to bring in modules from dojo, dijit, dojox, and mypackage (with no other special configuration).

In the case where dojo, dijit, and dojox contain the Dojo 1.7RC2 source, this works fine. However, if I swap out dojo, dijit, and dojox with the respective folders from the 1.7RC2 *release* (i.e. prebuilt) tarball, modules in mypackage are no longer looked up correctly - they are looked for under dojo/mypackage instead of just mypackage.

I tried removing async:true out of curiosity, but the same thing happens. I haven't yet tried replacing require with dojo.require since it'd be a more lengthy operation.

Is this something that's supposed to work? I thought in the past that mixing source of custom packages/namespaces with built dojo/dijit/dojox didn't pose a problem.

I'm marking this ticket as Loader, but I'm not sure really whether it's more on that end or the BuildSystem? end.

[UPDATE] I also just tried a full-blown build (no layers, just prefixes to get mypackage built alongside everything else), and still see the same issue.

Change History (6)

comment:1 Changed 8 years ago by Kenneth G. Franqueiro

Cc: Rawld Gill removed
Description: modified (diff)
Summary: source in custom namespaces work against dojo 1.7.0rc2 src but not releasesource in custom namespaces work against dojo 1.7.0rc2 src but not against built

comment:2 Changed 8 years ago by Kenneth G. Franqueiro

I have an update to this, may have narrowed down what is causing the issue.

This issue does not occur in just any custom namespaced package; however, the packages in the project I've been trying to build with (dgrid) have package.json files. If I remove/relocate those files and rebuild, the test pages no longer wrongly attempt to load these packages from underneath the dojo package's directory.

The package.json for the respective packages in question can be viewed here: https://github.com/SitePen/dgrid/blob/master/package.json https://github.com/kriszyp/xstyle/blob/master/package.json https://github.com/kriszyp/put-selector/blob/master/package.json

Is there anything that stands out in these package.json files? Should something be changed in them, or on the builder or loader end?

comment:3 in reply to:  2 ; Changed 8 years ago by Rawld Gill

Replying to kgf:

I have an update to this, may have narrowed down what is causing the issue.

[snip]

Is there anything that stands out in these package.json files? Should something be changed in them, or on the builder or loader end?

The profiles look fine.

It might be interesting to run the builds you are attempting with the --check command line switch both with and without the package.json files present and look at the differences.

Also I'm not sure I understand if you (and Kris http://mail.dojotoolkit.org/pipermail/dojo-contributors/2011-October/025780.html) are trying to use unbuilt grid project with prebuild dojo, or build a whole project, including grid. Are these two separate problems or the same?

Could you reduce to a single-module project and post?

comment:4 in reply to:  3 Changed 8 years ago by Kenneth G. Franqueiro

Replying to rcgill:

Replying to kgf:

I have an update to this, may have narrowed down what is causing the issue.

[snip]

Is there anything that stands out in these package.json files? Should something be changed in them, or on the builder or loader end?

The profiles look fine.

It might be interesting to run the builds you are attempting with the --check command line switch both with and without the package.json files present and look at the differences.

I've given that a shot, reducing my test to just using put-selector. The only changes produced are the following... (left is with package.json, right is without)

Within the put-selector key of the destPackages hash:

< 					 main:"put",
---
> 					 main:"main",

Within the put-selector key of the packages hash:

< 					 main:"put",
---
> 					 main:"main",

< 					 packageJson:{
< 					 		author:"Kris Zyp",
< 					 		description:"A high-performance, lightweight function for creating and manipulating DOM elements with succinct, elegant, familiar CSS selector-based syntax",
< 					 		directories:{lib:"."},
< 					 		icon:"http://packages.dojofoundation.org/images/xstyle.jpg",
< 					 		licenses:[
< 					 				{
< 					 					 type:"AFLv2.1",
< 					 					 url:"http://trac.dojotoolkit.org/browser/dojo/trunk/LICENSE#L43"
< 					 				},
< 					 				{
< 					 					 type:"BSD",
< 					 					 url:"http://trac.dojotoolkit.org/browser/dojo/trunk/LICENSE#L13"
< 					 				}
< 					 		],
< 					 		main:"./put",
< 					 		maintainers:[{
< 					 					 email:"kriszyp@gmail.com",
< 					 					 name:"Kris Zyp"
< 					 				}],
< 					 		name:"put-selector",
< 					 		selfFilename:"/Users/kgf/Sites/sitepen/git/dgrid-buildtest/put-selector/package.json",
< 					 		version:"0.2.0"
< 					 },
---
> 					 packageJson:0,

Also I'm not sure I understand if you (and Kris http://mail.dojotoolkit.org/pipermail/dojo-contributors/2011-October/025780.html) are trying to use unbuilt grid project with prebuild dojo, or build a whole project, including grid. Are these two separate problems or the same?

We are referring to the same issue, which occurs both with unbuilt dgrid/xstyle/put-selector next to built (e.g. non-src tarball) dojo/dijit/dojox, as well as if I build them all together using a custom build. This has me particularly perplexed, since it would suggest it's more than just the build factoring in, but I've never seen any sign of the loader checking package.json files, so I'm willing to think I'm still missing something...

Could you reduce to a single-module project and post?

This should be reproducible simply by throwing the put-selector package source (https://github.com/kriszyp/put-selector/tarball/v0.2.0) into a put-selector directory that is a sibling to built dojo/dijit/dojox, or by throwing it next to src dojo/dijit/dojox/util and running a build. The profile I used is literally no more than the following:

dependencies = {
	action: "release",
	releaseName: "pstest",
	
	prefixes: [
		[ "dijit", "../dijit" ],
		[ "dojox", "../dojox" ],
		[ "put-selector", "../put-selector" ]
	]
}

I added the following simple page under put-selector/test to test:

<!DOCTYPE html>
<html>
	<body>
		<script src="../../dojo/dojo.js" data-dojo-config="async:true"></script>
		<script>
require(["put-selector/put"], function(put){
	console.log(put);
});
		</script>
	</body>
</html>

This test page is enough to induce a 404 for the put module in the problem cases above, but against all source (or without package.json) it appears to work.

comment:5 Changed 8 years ago by Rawld Gill

Resolution: fixed
Status: newclosed

In [26901]:

fixed typo; fixes #14133

comment:6 Changed 8 years ago by Rawld Gill

Thanks Ken, that's a great diagnostic you gave me!

I found and fixed [26901] a typo in the build app that which should make your test work (I was able to dup the error and the repair makes the error go away on my machine).

I also noticed that put-selector/put.js uses a module pattern that assumes the absolute module id is not given. By default, the build system inserts module ids so the built modules can work by including in a plain-old-script element (for backcompat). To eliminate this default, use the command-line flag --insertAbsMids 0 (any falsy value will do). You could also put that in the profile.

Note: See TracTickets for help on using tickets.