[library resolver] local waypoints.

[favonia]

This is the spec of waypoints that point to local library roots. A library reference in this scheme is a string library.name. Waypoints are stored in YAML files of a name specified by the client. Maybe it's waypoint. This special file name is referred to as ${waypoint} below.

Direct waypoints

These are the basic waypoints pointing to the roots of libraries. The resolver will keep moving up in the file system until some matching waypoint is found. If the root directory is reached and there's still no matching waypoint, the resolution fails.

- "basis":
    at: ["src", "basis"]
- "frontend":
    at: ["src", "frontend"]

Indirect waypoints

Indirect waypoints delegate the resolution to other waypoints, which can also be indirect. The resolution is thus recursive. The library name must be explicitly listed in the next waypoint file. That is, it will not move up in the file system when no applicable waypoint is found. Otherwise, one can easily have unintentional infinite looping due to a typo.

- "bantorra":
    "next": ["mylib", "bantorra"] # the resolver will look up the library in "mylib/bantorra/${waypoint}"
- "cool.basis":
    "next": ["mylib", "cool"] # the resolver will look up the library in "mylib/cool/${waypoint}"
    "rename": "basis" # optional field for the new name to look up

Mixed waypoints

Of course, you can have both direct and indirect waypoints in a single file.

- "cool.basis":
    "next": ["mylib", "cool"]
    "rename": "basis"
- "bantorra":
    "next": ["mylib", "bantorra"]
- "builtin":
    "at": ["runtime", "builtin"]

Name uniqueness

The YAML format demands unique library names within a waypoint file, so there should not be any ambiguity. The order of waypoints in a file should not matter.