Opened 14 years ago

Closed 11 years ago

#5959 closed defect (wontfix)

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

Reported by: alex Owned by: Rawld Gill
Priority: high Milestone: 2.0
Component: Loader Version: 1.0
Keywords: Cc: james
Blocked By: Blocking:

Description (last modified by 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

Change History (11)

comment:1 Changed 14 years ago by alex

Milestone: 1.21.1
Status: newassigned

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

comment:2 Changed 14 years ago by alex

Cc: james added
Milestone: 1.11.2

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

comment:3 Changed 14 years ago by Brad Neuberg

Resolution: fixed
Status: assignedclosed

(In [13035]) fixes #5959

comment:4 Changed 14 years ago by James Burke

Resolution: fixed
Status: closedreopened

Ticket accidentally closed. This ticket has not been resolved.

comment:5 Changed 14 years ago by alex

Description: modified (diff)
Milestone: 1.21.4

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.

comment:6 Changed 14 years ago by 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).

comment:7 Changed 12 years ago by James Burke

Milestone: 1.42.0

comment:8 Changed 11 years ago by Chris Mitchell

Owner: changed from alex to dylan
Status: reopenednew

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

comment:9 Changed 11 years ago by dylan

Owner: changed from dylan to Rawld Gill

Rawld, putting this one on your radar for 2.0.

comment:10 Changed 11 years ago by Rawld Gill

Status: newassigned

comment:11 Changed 11 years ago by Rawld Gill

Resolution: wontfix
Status: assignedclosed

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:


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.

Note: See TracTickets for help on using tickets.