class

Analyzer::Javascript::Sails

Inherits Analyzer::Javascript::JavascriptEngine < Analyzer < FileHelper < Reference < Object

Sails.js routes come from two sources:

Explicit routes hand-written in config/routes.js -- an object literal mapping 'METHOD /path' address strings to targets (controller/action strings, {controller, action} objects, inline handler functions, view/redirect targets, ...).
Blueprint routes Sails auto-generates per controller/model unless disabled, plus the "actions2" convention of one file per action under api/controllers/<subdir>/<action>.js, whose URL is the action's path relative to api/controllers (no extension).

Both are gated on discover_sails_roots, which requires a config/routes.js file AND a package.json declaring the sails dependency in the SAME directory -- not either alone. Node projects are noir's most crowded language (Express/Koa/Nest/Fastify/Hapi/Restify all coexist), and blueprint inference in particular works off file presence rather than an explicit registration call, so it is especially prone to stealing routes from a neighboring framework's api/controllers/*.js-shaped tree in the same repo (the exact class of bug the #2417-2432 project-scoping campaign fixed for other analyzers).

Constants

ADDRESS_LINE_RE = /^[ \t]*['"]((?:[A-Za-z]+[ \t]+)?\/[^'"]*)['"][ \t]*:/m

One quoted-key route entry per line is the universal routes.js style (every official example and every real app follows it). The captured group requires the string to actually look like a route address -- an optional method name followed by /... -- so nested option keys inside a target object (locals: {...}, cors: {...}) can't be mistaken for a sibling route entry: those keys are bare identifiers, never quoted strings immediately followed by :.

Address verbs recognised in config/routes.js route keys. ALL matches any method (expanded below); QUERY is accepted for parity with the rest of noir's JS analyzers even though Sails' own docs don't mention it explicitly -- an app that wires one up by hand still deserves to be reported.

BLUEPRINT_ROUTES = [{"GET", ""}, {"POST", ""}, {"GET", "/:id"}, {"PATCH", "/:id"}, {"DELETE", "/:id"}]

{method, sub-path} pairs generated for every blueprint-eligible controller/model identity, mirroring Sails' current (>=1.0) default REST blueprint bindings: find/create/findOne/update/destroy. Association routes (populate/add/remove/replace) and the dev-only shortcut GET routes are intentionally not modeled -- see the PR description for the reasoning.

CONTROLLER_FILE_RE = /\A([A-Za-z0-9_]+)Controller\.(js|ts|mjs|cjs)\z/

HTTP_METHODS = ["GET", "POST", "PUT", "DELETE", "PATCH", "HEAD", "OPTIONS"] of ::String

JS_SOURCE_EXTENSIONS = [".js", ".ts", ".mjs", ".cjs"]

MODEL_FILE_RE = /\A([A-Za-z0-9_]+)\.(js|ts|mjs|cjs)\z/

PACKAGE_MARKER = /"sails"\s*:\s*"/

ROUTES_FILE_SUFFIX = "/config/routes.js"

Class methods

tech_name

Source

Instance methods

analyze

Source

tech

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.

Source