change of wire dependency resolution from 10.1 to 10.2

[DaniHaag]

in wire 10.1 relative modules where retrieved locally from the base directory in wire 10.2 relative modules are relative to the context file. Has this behavior changed on purpose? Will it stay like this?

I create the modules like this:

entity : {
        create : {
            module : '../../entity/AnyEntity',
        }
    },

[briancavalier]

Hi @DaniHaag. Yes, you're right, it did change in 0.10.2. The problem was that the behavior of relative ids in context files ("wire specs") was very inconsistent across platforms (e.g. node vs. amd+browser), and even across different AMD loaders (e.g. curl vs. requirejs). Since wire simply passed module ids verbatim through to the underlying module system, the module system would handle them in an implementation specific way.

This had some nasty side effects:

1. relative ids were effectively useless for many projects--they were no better than using absolute ids.
2. using wire specs as a composition plan for coarse-grained components (e.g. a view that has JS, html, css, etc.) was tough. Ideally you would keep all the related files, including the wire spec, in the same subdir tree as a self-contained, relocatable component and simply reference modules in the wire spec using nice, short, relative ids like ./ViewController.js, etc. That was impossible, and if you ever had to move that type of large component around in your project, it would break.

Prior to 0.10.2, we didn't recommend using relative ids in wire specs for those reasons, and we had quite a few requests to make spec-relative ids work.

In 0.10.2+, relative module ids in a spec will always be treated, as you said, as relative to the spec itself. This makes the behavior consistent across platforms and module system. It also makes it much easier to create larger, reusable components and to structure an application using a hierarchy of wire specs.

I apologize if this has caused you some headaches. We feel strongly that ids being spec-relative is a much better situation going forward, though. The 0.10.2 behavior will stay for the foreseeable future.

I'll close this since it sounds like 0.10.2 is working as intended, but please feel free to continue the discussion if you have questions about it, or see any problems with how it's working now.