Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

sails

Package Overview
Dependencies
Maintainers
4
Versions
236
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

sails - npm Package Compare versions

Comparing version 1.4.0 to 1.4.1

docs/anatomy/.editorconfig.md

2

lib/EVENTS.md

@@ -34,3 +34,3 @@ # Core Events

If you want to add/trigger events to monkeypatch your Sails core, it's best to do this by authoring a hook. More information will show up as we learn more about best practices around that process, but one thing we've definitely learned is that you're better off namespacing your events and firing them on a single object (`sails`), then emitting and listening on different objects. Why? Sometimes objects get deleted or copied, and this can make a big mess.
If you want to add/trigger events to monkeypatch your Sails core, it's best to do this by authoring a hook. More information will show up as we learn more about best practices around that process, but one thing we've definitely learned is that you're better off namespacing your events and firing them on a single object (`sails`), than emitting and listening on different objects. Why? Sometimes objects get deleted or copied, and this can make a big mess.

@@ -37,0 +37,0 @@ If you need a special event in your hook, you *will* want to namespace it. For instance, if I'm adding a hook called `enforceRestfulSesssions` that limits the actions that can be added to controllers to encourage code consistency, I might have a `hook:enforceRestfulSesssions:checked` event that fires when all of the controllers have been checked. This is so that other hooks that know about `enforceRestfulSesssions` can wait until it has finished its check before proceeding (whether it's just me, or other people on my team, or if I release my hook and it gets popular, other people in the Sails community).

{
"name": "sails",
"author": "Mike McNeil <@mikermcneil>",
"version": "1.4.0",
"version": "1.4.1",
"description": "API-driven framework for building realtime apps, using MVC conventions (based on Express and Socket.io)",

@@ -61,3 +61,3 @@ "license": "MIT",

"rttc": "^10.0.0-0",
"sails-generate": "^2.0.0",
"sails-generate": "^2.0.3",
"sails-stringfile": "^0.3.3",

@@ -64,0 +64,0 @@ "semver": "4.3.6",

@@ -24,7 +24,2 @@ # [![Sails.js logo](http://balderdashy.github.io/sails/images/logo.png "Sails.js")](http://sailsjs.com)

> ##### Upgrading from an earlier version of Sails?
>
> Available as of Node >=v7.9 and Sails >=v1.0, ES8's async/await enables dramatic improvements to the way developers build Node.js / Sails apps. It allows server-side JavaScript code to be written with the `await` keyword, instead of lower-level (and more fragile) flow control mechanisms like nested callbacks and promise chains. It lets developers breathe easier by removing the burden of painstaking, manual error handling after every database query. And best of all, it means **the end of "callback hell"**: the most common source of bugs and stability issues in real world Node.js / Sails applications.
>
> If ES8 isn't for you, don't worry-- Node callbacks and promise chaining are still fully supported. But for most teams, the transition to `await` results in sizable gains in productivity, with fewer lines of code.
>
> Upgrade guides for all major releases since 2013 are available on the Sails website under [**Upgrading**](http://sailsjs.com/upgrading).

@@ -31,0 +26,0 @@

Sorry, the diff of this file is not supported yet

Sorry, the diff of this file is not supported yet

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc