Introduce a convention for specifying relative paths in middleware
params: values prefixed with `$!` and starting with `./` or `../`
are resolved relatively to `middleware.json`.
Example:
{
"files": {
"loopback#static": {
"params": "$!../client"
},
"loopback#static": {
"params": "$!./public"
}
}
}
When the middleware name (path) is in the format {module}#{filename},
loopback-boot resolves the path by trying multiple locations and
using the first one that exists:
- {module} and check the {filename} property of the exports
-> e.g. loopback.rest
- {module}/server/middleware/{filename}
-> e.g. loopback/server/middleware/rest
- {module}/middleware/{filename}
-> e.g. loopback/middleware/rest
Values in any other format will bypass this resolution algorithm and
they will be used in the original form:
- a full path in a module: loopback/server/middleware/rest
- a relative path: ./middleware/custom, ./custom, ../logger
- an absolute path: /usr/local/lib/node_modules/compression
Sample JSON:
{
"routes:before": {
"morgan": {
"params": ["dev"]
}
},
"routes": {
"loopback/server/middleware/rest": {
}
},
"subapps": {
"./adminer": {
},
}
}
The JSON file can be customized using the usual conventions:
- middleware.local.{js|json}
- middleware.{env}.{js|json}
It is also possible to mount the same middleware in the same phase
multiple times with different configuration.
Example config:
{
"auth": {
"oauth2": [
{
"params": "first"
},
{
"params": "second"
}
]
},
});
jshint does not support `trailing` as of v1.5.0.
Remove `maxlen` too, jscs provides better implementation.
Fix definition of global mocha variables - mark them as immutable.
Load models for any filetypes registered in require.extensions.
- Server side coffee-script requires a `require('coffee-script/register');`
- Client side coffee-script requires Coffeeify.
Interpret model sources in the same way how `require.resolve`
interprets the path:
- values starting with `./` and `../` are relative to the file
where they are specified
- other values are relative to node modules folders
This way it's possible to specify a source `loopback/common/models`
and have it resolved to whatever place the loopback is installed.
LoopBack built-in models are special: they follow the loopback-boot
structure and provide `common/models/{name}.json` files, but they are
also automatically loaded (created) by loopback.
This change modifies `executor` to recognize built-in models and do not
redefine them.
Ryan Graham
Miroslav Bajtoš
Miroslav Bajtoš
Raymond Feng
Raymond Feng
bitmage
johnsoftek
Shelby Sanders