the package system should add a "../../name" convention

[alex]

currently, we support transparent peering of modules if they are direct siblings of the directory in which dojo.js exists. This is inconvenient as, in many cases, these modules exist in locations (at least) one more level up in the filesystem hierarchy. In particular, a release copy of Dojo includes an intermediate "dojo-1.x.x-release/" directory, which is often checked into source control as an "immutable" or 3rd-party resource.

It would be better, then, if in addition to the current "../name" auto-peering we also implement "../../name" auto-peering, with "../../name" likely taking precedence

[alex]

discussed with james, needs good docs in release notes and book authors need to be notified of the change (there are caveats for x-domain), but otherwise we should land this for 1.1

[alex]

after a *much* longer discussion, seems we need to punt. It's just really hairy.

[Brad Neuberg]

(In [13035]) fixes #5959

[James Burke]

Ticket accidentally closed. This ticket has not been resolved.

[alex]

no solution in time for 1.2. Moving to 1.4, as I don't know that there will be time to work on this again before then.

[alex]

for the record, the best solution here is clearly a backwards-incompatible change to the "../name" convention to implement *only* "../../name" instead. No interim solution appears possible which does not either introduce a likely 404 for the common case (unacceptable) or a necessary configuration change for existing users (defeating the point of the whole "backwards compatibility" thing).

[Chris Mitchell]

please review/triage. this one likely wont happen in the same way with amd

[dylan]

Rawld, putting this one on your radar for 2.0.

[Rawld Gill]

Loader semantics have changed with the introduction of AMD making this issue solvable in several ways.

By default, the v1.x loader:

• sets baseUrl to point to the dojo path (e.g., the dojo directory)
• computes top-level-module ids to be siblings of the dojo path

For example, given:

path/to/dojo/
  dojo.js
  AdapterRegistry.js
  aspect.js
  ...

baseUrl is path/to/dojo, and the module "foo" would resolve to path/to/dojo/../foo.js => path/to/foo.js. Notice the /../ causes the module to be a sibling to dojo path. Similarly, the module foo/bar resolves to path/to/foo/bar.js.

If you do not desire top-level-modules to be siblings to dojo, set the has.js feature "config-tlmSiblingOfDojo" to falsy. This results in *not* applying the /../ path.

If you desire to place a top-level module in a particular location, either use a package config or a paths config.

If you desire to have baseUrl have nothing to do with dojo so that top-level modules can be resolved with respect to baseUrl without dojo's influence, then provide a package config for dojo, set config-tlmSiblingOfDojo to falsy, and baseUrl as desired.