Flexible Path Conventions
bundleRelative VS fileRelative paths
You can use bundleRelative (i.e. absolute 'depdir/dep') or fileRelative (i.e relative to requiring file '../../dep') paths interchangeably:
On node, dependencies are relative ONLY to requiring file (aka fileRelative), which I feel is a source of misconceptions on modularization it self, in regards to development: what happens if you move a file ? What does that dotted path semantically represent in your project structure ?
Vanilla AMD/RequireJS on browser works with
fileRelative, but also allows an absolute bundleRelative path likemodels\PersonModel, relative to some 'bundle', i.e.baseUrl.
uRequire allows you to use both semantics, no matter what you write in (nodejs/AMD), as it converts them (at build and execution time on node) to work on both runtimes.
Mix them up
There are cases both fileRelative and bundleRelative are usefull, so mix them up!
One core aim of uRequire is to allow you to use either on both environments.
At build time everything is translated to what actually works (fileRelative), so you dont need to worry. And at runtime, even if you come to evaluate to an absolute path (which you normally shouldn't), it will still work (by default) on web and by (transparent) translation on nodejs.
Actually mixing the two path formats, is IMHO probably a good practice:
When you require a local dependency, eg. something closely related to your current module, you could use the fileRelative notation. For instance if you are writing
utils/string/camelCaseand you needutils/string/replaceAllChars, then its logical, obvious and self explanatory to just use./replaceAllChars.When you require something more distant, you should use the absolute path to show exactly what you mean. For instance,
../../../string/replacereveals little of where is what you need, where you coming from and whether it is the right path. And if you ever refactor it'll be a nightmare to change 'em all. Its actually more clear to useutils/string/replacein these cases.
