balderdashy/sails
56.7
Adequate · 1 October 2026
14.9k
lines of production code
JavaScript
primary language
2
measurements over time
What this system is
This system is the Sails.js framework, a Node.js application framework built on a modular, hook-based architecture that manages the application lifecycle through distinct components like HTTP, routing, and security. It provides core capabilities for building web applications, including RESTful blueprint generation, real-time pub/sub via WebSockets, and structured error handling with improved user-facing messages. The system also exposes a programmatic API for configuration loading, command-line interface operations, and integration testing, ensuring a standardized environment for development and deployment.
How it got here
2012–2013 — Sails 1.0 modular architecture rewrite
21 changes.
This period focused on restructuring the Sails framework into a modular, hook-based architecture, replacing monolithic components with dedicated modules for the CLI, router, and core lifecycle. The work established a standardized hook system with explicit lifecycles, refactored internal hooks like HTTP, views, and sessions for better configuration and stability, and introduced a comprehensive event system for developers. Additionally, it modernized the codebase by updating dependencies, improving error handling, and preparing the foundation for the Sails 1.0 release.
2014 — test infrastructure and core refactoring
21 changes.
This period focused on establishing a robust testing foundation by adding comprehensive unit, integration, and benchmark suites for Sails' core hooks, lifecycle, and routing. Concurrently, the framework underwent significant internal refactoring, including restructuring the application lifecycle modules and enhancing the responses hook to improve security and default behavior.
2016–2017 — security consolidation and helper refactoring
11 changes.
This period focused on consolidating security configurations into a unified hook with stricter CORS and CSRF handling, while refactoring controller and helper loading logic for better validation and error reporting. The work also involved inlining utility libraries to reduce dependencies, exposing internal utilities for programmatic access, and improving CLI and REPL functionality.
Features
Introduce userconfig hook for centralized configuration loading
A new \userconfig\ hook has been added to the framework to handle the loading and merging of application-level configuration. This hook is designed to load first, utilizing the \moduleloader\ to fetch user configuration from the \config\ directory and merging it with existing settings via the \merge-dictionaries\ library. It also ensures that \appPath\ defaults to the current working directory if not explicitly set, providing a standardized entry point for configuration management before other hooks initialize.
lib/hooks/userconfig · high confidence
Behavioural changes
Blueprint actions now support deep socket subscriptions and association change notifications
The blueprint actions (add, create, destroy, find, findOne, populate, remove, replace, update) have been updated to automatically subscribe requesting sockets to the primary records they interact with, as well as to deeply subscribe to all associated records via the new \subscribeDeep\ utility. Additionally, when records are added, removed, or created in a way that affects inverse associations, the system now sends \removedFrom\ notifications to the former parent records, ensuring that all affected clients receive real-time updates about association changes.
lib/hooks/blueprints/actions · high confidence
Blueprints hook refactored for Sails 1.0 with new configuration and behavior
The blueprints hook has been restructured for Sails 1.0, introducing a new \parseBlueprintOptions\ function to replace legacy configuration options like \defaultLimit\ and \populate\, which now trigger deprecation warnings. The hook now uses \@sailshq/lodash\ to resolve compatibility issues, removes JSONP support, and changes the default REST update method from PUT to PATCH. Additionally, blueprint actions are now explicitly bound with a \BLUEPRINT: \<action\>\ middleware type, and the \req.target\ property is deprecated in favor of \req.options\.
lib/hooks/blueprints · high confidence
Breaking changes to helper invocation defaults with backward-compatibility warning
The helpers hook now defaults to serial argument passing and automatic execution (removing the need for \.now()\ or \.execSync()\), which is a breaking change for apps relying on the previous dictionary-style named parameters and deferred execution. To prevent immediate breakage, the hook detects if the app's \package.json\ points to a Sails prerelease older than v1.0.0-44 and automatically reverts to the legacy configuration (\arginStyle: 'named'\, \execStyle: 'deferred'\) while displaying a detailed warning message. Users are advised to either update their code to use the new serial style or explicitly configure the legacy options in \.sailsrc\ to silence the warning and ensure stability.
lib/hooks/helpers · high confidence
CSRF protection now handles disabled sessions and socket requests securely
The CSRF security hook has been updated to prevent server crashes and improve error handling when sessions are disabled or requests come via WebSockets. If CSRF protection is enabled but the session is disabled, the system now returns a 'CSRF mismatch' error for non-safe HTTP methods (GET, HEAD, OPTIONS) instead of crashing or failing silently. Additionally, CSRF tokens are no longer granted via socket requests; attempting to do so in development returns a clear error, while production returns a 404 Not Found. The hook also ensures \res.locals.\_csrf\ is always initialized, even when CSRF checks are skipped, and improves route matching logic for blacklists and whitelists by ignoring GET, HEAD, and OPTIONS routes during list construction.
lib/hooks/security/csrf · high confidence
Consolidated security configuration with deprecated legacy options
The \cors\ and \csrf\ settings have been unified under the new \sails.config.security\ namespace. Legacy top-level \sails.config.cors\ and \sails.config.csrf\ options are now deprecated and will be automatically migrated to \sails.config.security.cors\ and \sails.config.security.csrf\ respectively, though users should update their configs to use the new paths. Several specific legacy properties have been renamed or removed: \origin\ is replaced by \allowOrigins\ (which now prefers an array over a comma-separated string for multiple origins), \credentials\ by \allowCredentials\, \headers\ by \allowRequestHeaders\, \methods\ by \allowRequestMethods\, and \exposeHeaders\ by \allowResponseHeaders\. The old \securityLevel\ CORS option is no longer supported and will cause a lift failure. Additionally, enabling CSRF globally now requires the session hook to be enabled, and legacy CSRF options like \routesDisabled\, \origin\, and \grantTokenViaAjax\ are no longer supported at the global level.
lib/hooks/security · high confidence
Default HTTP response handlers now prevent stack trace leakage in production
The default response methods (res.badRequest, res.ok, res.serverError, etc.) have been updated to ensure that error stack traces are never sent to the client in production environments. Previously, passing an Error instance to methods like res.ok() or res.badRequest() could inadvertently expose internal stack details via util.inspect() or JSON serialization. The new implementation checks the NODE\_ENV; in production, these methods will send a generic status code (e.g., 400 or 200) without body data if an Error is passed, or strip the stack trace before sending JSON. Additionally, res.negotiate() is now deprecated in favor of custom responses, and the default 403 (Forbidden) response no longer attempts to render a view.
lib/hooks/responses/defaults · high confidence
Expose internal utilities for programmatic access
The \generate\ function and the \rc\ configuration loader are now explicitly exposed via the \accessible/\ directory (e.g., \require('sails/accessible/generate')\ and \require('sails/accessible/rc')\). This allows users to programmatically invoke file generation and access command-line configuration loading without needing to install separate dependencies, although the maintainers note that the generator exposure is a breaking change and may be removed in the future if no strong use cases are identified.
accessible · high confidence
HTTP hook refactored with new middleware configuration and improved startup diagnostics
The HTTP hook has been restructured to use a new \sails.config.http\ configuration namespace, replacing the legacy \sails.config.express\ and \sails.config.cache\ settings. This change introduces a configurable middleware order (\sails.config.http.middleware.order\) that allows users to manage the stack of built-in middleware (such as \cookieParser\, \session\, \bodyParser\, and \www\) more flexibly. The hook now waits for the session hook to initialize before binding session middleware, ensuring proper configuration availability. Additionally, startup diagnostics have been enhanced with a 4-second lift timeout and specific troubleshooting messages for common issues like port conflicts or slow Grunt tasks. SSL support has been expanded to accept \pfx\ certificates, and the \trustProxy\ setting now strictly validates against falsy values like \0\ or \null\ to prevent misconfiguration.
lib/hooks/http · high confidence
Improved REPL history management and CLI command display
The REPL now persists command history across sessions by reading from and writing to a \.node\history\ file, with a one-time warning displayed if history writing fails. The CLI help output no longer shows the internal wildcard \\\ command, and version information is now explicitly displayed. These changes also resolve Node.js deprecation warnings related to asynchronous function usage and \fs.write\ signatures.
bin/private · high confidence
Inlined utility libraries for configuration and URL validation
The \lib/util\ directory now includes inlined versions of the \rc\ configuration loader and \deep-extend\ utility, alongside new validation helpers \checkOriginUrl\ and \detectVerb\. This change removes external dependencies for these specific functions by embedding their source code directly, ensuring that configuration parsing (including environment variable handling and file discovery) and HTTP verb detection operate without requiring the original npm packages. Users benefit from a more self-contained utility layer where origin URL validation strictly enforces protocol, port, and path constraints, and route parsing tolerates whitespace variations.
lib/util · high confidence
Introduce core logger hook using CaptainsLog
The logger hook has been implemented to initialize the CaptainsLog library, exposing the \sails.log\ function for application-wide logging and adding a \sails.log.ship()\ method that prints an ASCII ship graphic. The hook defaults the log level to 'info' and requires the moduleloader and userconfig hooks to be loaded first.
lib/hooks/logger · high confidence
Introduction of the 'responses' core hook
The legacy 'errors' hook has been renamed to 'responses' and refactored to manage both default and custom response modules. This change introduces built-in default responses (such as \ok\, \notFound\, \serverError\, \forbidden\, \badRequest\, and \negotiate\) that are automatically merged with user-defined custom responses from the \api/responses/\ directory. Additionally, the hook now supports binding routes directly to response modules using the \response\ key in route targets (e.g., \{ response: 'ok' }\), and it protects against overriding reserved \res\ properties to prevent recursion issues.
lib/hooks/responses · high confidence
Module loader hook refactored to expose \`sails.modules\` and support diverse file extensions
The \moduleloader\ hook has been restructured to serve as the foundational core hook that exposes the \sails.modules\ API, allowing other hooks to load modules from configured paths. This change introduces support for a wider range of JavaScript dialects (including TypeScript, ES6, CoffeeScript, and LiveScript) via the \common-js-file-extensions\ library and enables loading of JSON and JSON5 configuration files. Additionally, the hook now prioritizes \config/local.js\ for environment settings and loads environment-specific configurations from \config/env/\<env\>/\, ensuring that local overrides take precedence over other configuration sources.
lib/hooks/moduleloader · high confidence
New private module structure for Sails app lifecycle and configuration
The \lib/app/private\ directory has been restructured into a set of dedicated modules that manage the Sails application lifecycle and configuration. \initialize.js\ now handles the server startup sequence, including process signal listeners (SIGINT, SIGTERM, SIGUSR2) and the emission of the \ready\ event. \bootstrap.js\ manages the execution of the user-defined bootstrap function, supporting both callback-based and async/await patterns with a configurable timeout (defaulting to 30 seconds). \loadHooks.js\ orchestrates the loading of core and user hooks, applying defaults and handling timeouts. \exposeGlobals.js\ controls the exposure of global variables (\sails\, \async\, \\_\) based on \sails.config.globals\, defaulting to disabled for better programmatic usage. \after.js\ provides an \emitter.after()\ utility for handling events that may have already fired. Additional modules include \checkGruntConfig.js\ for validating Grunt hook presence, \inspect.js\ and \toJSON.js\ for improved debugging and serialization of the Sails instance, and \isLocalSailsValid.js\/\isSailsAppSync.js\ for validating local Sails installations.
lib/app/private · high confidence
New security hook with improved CORS handling
The CORS logic has been consolidated into a new 'security' hook, replacing the previous standalone implementation. This update introduces a custom CORS header-setting module that prevents information leakage by only sending Access-Control-Allow-Origin headers when the requesting origin is explicitly whitelisted. It also enforces stricter validation, such as blocking the combination of wildcard origins and credentials, and deprecates defining CORS origins as simple strings in favor of object configurations.
lib/hooks/security/cors · high confidence
Policies hook refactored with case-insensitive config and legacy support
The policies hook has been rewritten to normalize configuration, making policy names case-insensitive and allowing shorthand boolean values (\true\/\false\) instead of requiring arrays. It now supports legacy controller-based policy configuration by automatically expanding it to the new action-based syntax, while also introducing an \alwaysAllow\ pass-through policy and stricter validation for loaded policy modules.
lib/hooks/policies · high confidence
Pubsub hook initialization and model augmentation logic
The pubsub hook now explicitly waits for the ORM hook to load before augmenting models with resourceful pubsub methods (such as subscribe, publish, and watch). It also handles ORM reloads by re-applying these methods, ensuring that model instances correctly receive real-time updates and socket notifications after schema or data changes.
lib/hooks/pubsub · high confidence
Refactored Sails core into a modular, hook-based architecture
The Sails core application lifecycle has been restructured to rely on a hook system, moving logic for configuration, hook loading, router assembly, and middleware registration into dedicated modules within \lib/app\. This change introduces a new \Sails\ constructor that inherits from \EventEmitter\ and exposes public methods such as \load\, \lift\, \lower\, \getRouteFor\, \getActions\, and \registerAction\. The refactoring also replaces the previous logging mechanism with \captains-log\, switches the lodash dependency to \@sailshq/lodash\ to address specific issues, and adds Express-style router synonyms (\get\, \post\, \put\, \del\) for low-level route binding.
lib/app · high confidence
Refactored configuration loading with new CLI shortcuts and environment variable handling
The configuration subsystem has been restructured to centralize default hook definitions in a new \default-hooks.js\ module and implement a more robust configuration loading pipeline. Users benefit from new command-line shortcuts, including \--redis\ (which automatically configures Redis adapters for sessions and sockets), \--staging\, and \--prod\ for environment selection, while the legacy \--dev\ flag is now deprecated with a warning. The system now explicitly loads \.sailsrc\ and environment variables when Sails is loaded programmatically, using the \rc\ utility to humanize and merge environment variables into the configuration object. Additionally, the \merge-dictionaries\ library is used for config merging, and the \async\ dependency has been upgraded to version 2.1.2.
lib/app/configuration · high confidence
Refactored controller loading into a dedicated private module with improved validation and error handling
The controller loading logic has been extracted into a new \lib/app/private/controller\ directory, separating the concerns of loading action modules (\loadActionModules\) and registering actions (\helpRegisterAction\). This change introduces stricter validation for action identities, now allowing the '$' character in route bindings, and improves error reporting by wrapping config errors in \flaverr\ and suppressing stack traces for user errors. It also adds assertions to catch refactoring issues, handles uncaught errors in module loading, and ignores \.md\ and \.txt\ files during controller discovery.
lib/app/private/controller · high confidence
Refactored helper loading and iteration with stricter identity handling
The helper loading mechanism now strictly enforces that a helper's identity is derived from its filename, ignoring any explicit identity or description fields in the definition to prevent conflicts and improve error messages. Additionally, the system now warns users if they attempt to use action-specific properties (such as \responseType\, \viewTemplatePath\, or \statusCode\) within helper definitions, ensuring clearer separation between helpers and actions. A new internal iterator utility has been introduced to support deep traversal of helper packs, enabling better organization and debugging of nested helper structures.
lib/hooks/helpers/private · high confidence
Request hook refactored with new parameter handling and deprecation of legacy APIs
The request hook has been restructured into modular components to improve performance and clarity. \req.param()\ now explicitly prioritizes route parameters over body and query parameters, and a new \req.allParams()\ method is introduced to retrieve all parameters from the query string, body, and route path combined, replacing the deprecated \req.params.all()\. Server metadata (\req.port\, \req.baseUrl\) is now derived from HTTP headers to support proxy environments correctly. Additionally, \req.validate()\ is deprecated and throws an error directing users to \actions2\, while legacy properties like \req.isJson\ and \req.isAjax\ are removed in favor of standard Express properties.
lib/hooks/request · high confidence
Restructured core library into an npm package with documented event system
The Sails core has been restructured into a standalone npm module located in the \lib\ directory, exposing a singleton instance via the main entry point while also making the \Sails\ constructor accessible as \sails.Sails\ for creating new app instances. This change introduces a comprehensive event system for core contributors and hook developers, documented in \EVENTS.md\, which includes lifecycle events (like \lifted\, \ready\, \lower\), router events (such as \router:bind\, \router:after\, \router:request\), and utility methods like \sails.after()\ for waiting on specific states. The \README.md\ provides an overview of the core structure and stability index for contributors.
lib · high confidence
Router refactored to use a private Express instance for virtual requests
The core router now uses a private, internal Express instance to handle virtual requests (such as those from Socket.io or unit tests) instead of routing them directly to the external HTTP server. This change introduces a new \bindDefaultHandlers\ module for standardized 404 and 500 error responses, updates the request/response building logic to better support mock streams, and ensures that route binding and unbinding events are properly emitted for internal routing. Users will see more consistent error handling for unmatched routes and server errors in non-HTTP contexts, and the router becomes more decoupled from the specific HTTP implementation.
lib/router · high confidence
Sails CLI commands are split into dedicated modules
The \bin\ directory has been refactored to replace the monolithic \sails.js\ entry point with dedicated command modules (e.g., \sails-lift.js\, \sails-console.js\, \sails-new.js\, \sails-debug.js\, \sails-inspect.js\, \sails-run.js\, \sails-migrate.js\, \sails-deploy.js\, \sails-upgrade.js\, \sails-www.js\, \sails-generate.js\). This change improves modularity and allows commands like \sails console\ to support a \--dontLift\ flag for non-HTTP usage, introduces \sails inspect\ for modern Node debugging, and standardizes how each command resolves and uses the locally-installed Sails version.
bin · high confidence
Services hook now exposes services via shallow merge and configurable globals
The services hook has been refactored to initialize \sails.services\ in the \configure\ phase and populate it via a shallow merge in \loadModules\, ensuring the registry exists before other hooks load. Services are now exposed globally only if \sails.config.globals.services\ is true, and the hook uses \@sailshq/lodash\ for module loading and merging.
lib/hooks/services · high confidence
Session hook refactored with new configuration validation and socket session support
The session hook has been restructured to provide more robust configuration validation and improved support for Socket.IO sessions. Configuration now strictly enforces that \sails.config.session.cookie.secure\ is a boolean and validates the session secret, throwing clear errors for invalid setups. The hook now supports custom session adapters via a \handleConstructingSessionStore\ hook, allowing developers to integrate third-party stores like \connect-mongo\ or \connect-redis\ more flexibly. Additionally, socket connections now automatically generate and maintain sessions, ensuring session data is persisted for WebSocket requests even without cookies. The old \routesDisabled\ config option has been replaced by \isSessionDisabled\, which accepts a function to dynamically determine when sessions should be skipped.
lib/hooks/session · high confidence
Standardized hook lifecycle and configuration API
The hook system now enforces a consistent structure for defining and loading hooks. Users must define hooks using specific reserved properties (\defaults\, \configure\, \loadModules\, \initialize\) rather than arbitrary methods, with validation errors thrown for misuse of reserved names like \config\ or \middleware\. The \initialize\ method now supports both callback-based and Promise-based asynchronous execution, automatically detecting the style to handle errors and callbacks correctly. Additionally, hooks can now be configured to load only in specific environments via the \envs\ configuration array, and route binding is managed through dedicated \routes.before\ and \routes.after\ hooks integrated with the router's lifecycle events.
lib/hooks · high confidence
Structured error handling with improved user-facing messages
The errors module has been reorganized into distinct categories (fatal, warn) and now uses the \captains-log\ library for consistent output. Fatal errors during app lift or load now suppress full stack traces for user-fixable issues (like missing adapters or invalid connections), providing clearer troubleshooting tips instead. Additionally, fatal errors are thrown rather than terminating the process when running in the test environment, preventing unintended test failures.
errors · high confidence
User hooks can now be explicitly filtered via configuration
The \userhooks\ hook now respects the \sails.config.loadHooks\ configuration option. When this option is set, only user hooks explicitly listed in the array will be loaded; any other user hooks found in the hooks directory are skipped. This allows users to selectively enable specific user plugins without disabling the entire user hooks mechanism.
lib/hooks/userhooks · high confidence
Views hook refactored with new configuration and rendering architecture
The views hook has been restructured into modular sub-components (configure, render, res.view, etc.) to support a new configuration system. The legacy \config.views.engine\ option is deprecated in favor of \config.views.extension\ (defaulting to 'ejs') and \config.views.getRenderFn\ for custom engines. Layout support is now built-in for EJS via a custom rendering function, while custom engines must implement their own layouts. The hook also introduces \sails.renderView()\ for programmatic rendering, enhances \res.view()\ with better locals merging and path inference, and adds client-side data exposure utilities (\htmlScriptify\) with deep HTML entity escaping and unescaping.
lib/hooks/views · high confidence
i18n hook switches to i18n-2 and adds request-level locale methods
The i18n hook now uses the i18n-2 library instead of the previous i18n-node implementation, requiring locale files to use the .json extension. This change introduces request-level methods req.getLocale() and req.setLocale(), and ensures that if the i18n hook is disabled (e.g., empty locales array), the global \\ and i18n functions remain available as passthroughs to prevent crashes in existing code.
lib/hooks/i18n · high confidence
Test coverage
Added benchmark tests for Sails load, lift, and HTTP request performance; Added integration test helpers for app lifecycle, HTTP, and sockets; Added test fixture controllers for integration testing; Added test fixture for generating sample user data; Added test fixtures for HTTPS integration testing; Added test fixtures for error and fake authentication policies; Added test fixtures for hooks, middleware, and configuration; Added test fixtures for views integration tests; Added test scaffolding for the Blueprints hook initialization; Added tests for HTTP hook initialization and configuration; Added tests for pubsub hook initialization dependencies; Added tests for request hook metadata, options isolation, and API availability; Added tests for the views hook; Added unit tests for core Sails application lifecycle and routing; Establishes test infrastructure and configuration; Expanded integration test coverage for Sails core hooks and generators; New test helpers for Sails lifecycle and routing; Updated test fixture configuration for sample app; Updated test fixture models for integration testing.
Dependencies
Sails framework v1.5.18 dependency manifest
The Sails framework (v1.5.18) now relies on a comprehensive set of dependencies including Express 4.22.2, Socket.io client 2.0.3, Waterline adapters (sails-hook-orm ^4.0.2, sails-hook-sockets ^3.0.0), and utility libraries like Lodash (@sailshq/lodash ^3.10.6) and EJS 3.1.10. Test fixtures for installable hooks have also been added to the project structure.
(dependencies) · high confidence
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
How this codebase got here
This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.
Score
- CAI 58 → 57 (-1.5)
- Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.
Lenses
- Code Health 54 → 53 (-0.7)
- Architecture 94 → 81 (-12.5)
- Maturity 57 → 57 (+0.0)
- Readiness 51 → 51 (+0.0)
- Security 99 → 97 (-2.2)
- Performance 75 (new)
Resolved (25)
- Documentation: no installation or build instructions (README.md)
- Documentation: no usage examples (README.md)
- Documentation: written for insiders (lib/hooks/session/README.md)
- addToCollection (cognitive 22) (lib/hooks/blueprints/actions/add.js)
- addToCollection (cyclomatic 20) (lib/hooks/blueprints/actions/add.js)
- buildRequest (cyclomatic 44) (lib/router/req.js)
- configure (cognitive 17) (lib/hooks/views/configure.js)
- createRecord (cognitive 25) (lib/hooks/blueprints/actions/create.js)
- createRecord (cyclomatic 22) (lib/hooks/blueprints/actions/create.js)
- exposeGlobals (cognitive 16) (lib/app/private/exposeGlobals.js)
- getBuiltInHttpMiddleware (cyclomatic 18) (lib/hooks/http/get-configured-http-middleware-fns.js)
- htmlScriptify (cognitive 33) (lib/hooks/views/html-scriptify.js)
- htmlScriptify (cyclomatic 19) (lib/hooks/views/html-scriptify.js)
- isLocalSailsValid (cognitive 16) (lib/app/private/isLocalSailsValid.js)
- iterateHelpers (cognitive 16) (lib/hooks/helpers/private/iterate-helpers.js)
- iterateHelpers (cyclomatic 16) (lib/hooks/helpers/private/iterate-helpers.js)
- lift (cyclomatic 17) (lib/app/lift.js)
- loadActionModules (cyclomatic 36) (lib/app/private/controller/load-action-modules.js)
- lower (cyclomatic 31) (lib/app/lower.js)
- parseBlueprintOptions (cyclomatic 58) (lib/hooks/blueprints/parse-blueprint-options.js)
- …and 5 more
New (68)
- Medium: security finding (details withheld)
- Medium: security finding (details withheld)
- Projects may be oversized for their cohesion
- Scanner failed to run — not a clean result
- add.addToCollection (cognitive 22) (lib/hooks/blueprints/actions/add.js)
- add.addToCollection (cyclomatic 20) (lib/hooks/blueprints/actions/add.js)
- bootstrap.runBootstrap (cognitive 16) (lib/app/private/bootstrap.js)
- configure.configure (cognitive 17) (lib/hooks/views/configure.js)
- create.createRecord (cognitive 25) (lib/hooks/blueprints/actions/create.js)
- create.createRecord (cyclomatic 22) (lib/hooks/blueprints/actions/create.js)
- exposeGlobals.exposeGlobals (cognitive 16) (lib/app/private/exposeGlobals.js)
- get-configured-http-middleware-fns.getBuiltInHttpMiddleware (cyclomatic 18) (lib/hooks/http/get-configured-http-middleware-fns.js)
- html-scriptify.htmlScriptify (cognitive 33) (lib/hooks/views/html-scriptify.js)
- html-scriptify.htmlScriptify (cyclomatic 19) (lib/hooks/views/html-scriptify.js)
- index.default (cognitive 17) (lib/hooks/security/cors/index.js)
- index.default (cognitive 216) (lib/hooks/pubsub/index.js)
- index.default (cognitive 25) (lib/hooks/http/index.js)
- index.default (cognitive 32) (lib/hooks/security/csrf/index.js)
- index.default (cognitive 41) (lib/hooks/moduleloader/index.js)
- index.default (cognitive 41) (lib/hooks/policies/index.js)
- …and 48 more
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
Survey your own repository
balderdashy/sails was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.
About this page
- The score is its most recent published measurement, taken on 1 October 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
- Measured at commit 7b76422cc27823df033572bdda5c4910a68b697f — the exact code this score is about.
- Scored under rubric-2026.09.18 — the same rubric and the same method as every other entry in this index.
- Measured by watchdog.canine.dev using codehealth-analyzer preprod-e569280dd5e2.