Opened 13 years ago
Closed 10 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 )
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 13 years ago by
Milestone: | 1.2 → 1.1 |
---|---|
Status: | new → assigned |
comment:2 Changed 13 years ago by
Cc: | james added |
---|---|
Milestone: | 1.1 → 1.2 |
after a *much* longer discussion, seems we need to punt. It's just really hairy.
comment:3 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:4 Changed 13 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Ticket accidentally closed. This ticket has not been resolved.
comment:5 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Milestone: | 1.2 → 1.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 13 years ago by
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 11 years ago by
Milestone: | 1.4 → 2.0 |
---|
comment:8 Changed 10 years ago by
Owner: | changed from alex to dylan |
---|---|
Status: | reopened → new |
please review/triage. this one likely wont happen in the same way with amd
comment:9 Changed 10 years ago by
Owner: | changed from dylan to Rawld Gill |
---|
Rawld, putting this one on your radar for 2.0.
comment:10 Changed 10 years ago by
Status: | new → assigned |
---|
comment:11 Changed 10 years ago by
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
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.
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