The locator gives semantic meaning to files on the filesystem. It does this with a set of "rules" that describes how each file path should be interpreted. In addition it groups files into "bundles". (Each bundle is usually an NPM module, but not always.)
The locator doesn't interpret the semantic meaning of the files. It is up to the user to understand and use the semantic meanings associated with the files.
Goals & Design
- provide an abstraction over filesystem paths
- set of "rules" (regexps basically) that determine the semantic meaning of each file
- files that match a rule (and thus have semantic meaning) are called "resources"
- built-in handling of "selectors", for resources that have multiple versions
- organize files in bundles
- bundles are usually NPM modules
- ...but can be something else, if an NPM module delivers multiple child bundles
- bundles are recursively walked, since they are often organized in a tree structure on disk
- bundles can have different types
- for example, a mojito application bundle is walked differently (uses a different ruleset) than a mojito mojit bundle
- each bundle can declare its type in its
package.json(for those bundles that are NPM modules)
- each bundle can also describe the type of child bundles found at certain paths (for e.g. mojito application that has mojit bundles at a certain place)
- the behavior of the locator should be configurable, which should include
- ...defining new rulesets, for new bundle types
- ...general runtime behavior configuration of returned values
Install using npm:
$ npm install locator
Example: Mojito Application
In your app's
"dependencies":..."mojito": "*"..."locator":"rulesets": "mojito/locator-rulesets"
Example: Defining Your Own Semantics
In your app's
locator-rulesets.js file which defines how to add semantic meaning to filesystem paths:
moduleexports =// nameKey defaults to 1// selectorKey has no default. selector is only used if selectorKey is givenmain:// we can use this to skip files_skip:/^tests?\b/i// where to find configuration filesconfigs:regex: /^configs\/\.$/i// where to find templatestemplates:regex: /^templates\/?\.[^\.\/]+\.html$/i// We use "selectors" because we might use different templates based// on different circumstances.selectorKey: 3// where to find CSS filescss:regex: /^public\/css\/\.css$/i;
Then, in your
app.js (or wherever makes sense to you) you can do something like:
var Locator = ;locator = ;var resources = locator;// access your "configs/foo.json" configuration file... resourcesconfigsfoo ...// access all your templatesObject;
Example: Defining Your Own Bundle Name
In your app's
"name": "usually-a-long-name-for-npm""locator":"name": "foo"
By default, locator will select the name of the bundle from the
package.json->name entry, but you should be able to specify a custom name by adding a
name entry under the
locator entry in package.json. This will help to decouple the name of the package from the urls that you will use to fetch those scripts from the client side.
This software is free to use under the Yahoo! Inc. BSD license. See the LICENSE file for license text and copyright information.
See the CONTRIBUTING.md file for information on contributing back to Locator.