Analyzer::Javascript::Feathers
Inherits Analyzer::Javascript::JavascriptEngine < Analyzer < FileHelper < Reference < Object
Feathers.js (https://feathersjs.com) is service-based rather than route-based: registering a service at a path auto-generates REST verbs from whichever of the standard CRUD methods the service implements.
app.use('/messages', new MessageService())
app.service('messages').hooks({ ... })
find(params) -> GET /messages get(id, params) -> GET /messages/:id create(data, params) -> POST /messages update(id, data, params) -> PUT /messages/:id patch(id, data, params) -> PATCH /messages/:id remove(id, params) -> DELETE /messages/:id
app.use(path, service, options) accepts an optional third
argument whose methods: array is the authoritative list of
externally exposed methods when present (v5 "Dove" API) — it is
honoured here as an intersection against whatever methods were
otherwise detected/assumed. The path and methods: value are
both frequently bare identifiers pointing at a sibling
<name>.shared.ts module in the current (v5/"Dove") CLI generator
layout (export const messagePath = 'messages', export const messageMethods = ['find', 'get', ...] as const) rather than
inline literals — both are resolved the same one-import-hop way
as the service class itself.
Constants
method name => {HTTP verb, needs a trailing /:id segment}
The officially documented Feathers database-adapter service base
classes (https://feathersjs.com/api/databases/adapters) — every
one of these implements the full CRUD set itself, so a subclass
that overrides none (or only some) of them still exposes all six
externally, unless narrowed by an explicit methods: option.
Class methods
Instance methods
Instance-side view of the same declaration. The per-file rescues live on
this base class, which has no way to name the analyzer that is running
inside them, so a skipped file could not be attributed to a tech.
Deriving it from analyzer_for keeps the name written exactly once.