SailsJS v1.0

This is just a list of changes that I would like to see in SailsJS v1.0. Many of these are breaking changes, but this is a major version bump, so now is the time to make these changes. It’s worth the upgrade pain to make some much-needed improvements to the framework and remove some legacy bloat and code smell.

Top Priorities:

Upgrade to Express 4.0

• Or Express 5.0, if it’s at least in beta by then

Trim-down SailsJS Core by moving a bunch of stuff to plug-ins (hooks)

• Remove Grunt, EJS, and LESS from SailsJS Core
• SailsJS Core should not include any build tool, view engine, or CSS preprocessor. These should all be plug-ins (hooks), so developers can choose whichever one they prefer - or none at all (useful for apps with no views - e.g. REST APIs)

Remove LoDash and Async globals

• It’s bad practice to expose these as globals
  • It creates a tight dependency that prevents us from removing LoDash/Async at some point in the future
  • It creates a tight dependency to specific versions of LoDash/Async
  • If developers are using LoDash/Async in their apps, then they need to define their own dependency on these modules and require() them just like any other module
    • This allows developers to use a different version of LoDash/Async than we use inside SailsJS
    • This allows SailsJS to ditch LoDash/Async in the future if we want

Switch to Yeoman Generators

• Yeoman has way more community adoption, support, and testing than SailsJS generators do
• Replace all of the SailsJS generators with Yeoman generators
• Create a generic SailsJS-to-Yeoman adapter so that existing third-party SailsJS generators can still be used
• The SailsJS CLI (e.g. sails new) will still work as it currently does, but it would spawn Yeoman under the hood
• The sails new generator would give the user their choice of SailsJS plug-ins to install as part of their new app - such as Grunt vs Gulp, LESS vs SASS, EJS vs Handlebars, etc. In all cases, the user can choose “none”

/config/bootstrap.js becomes /bootstrap/*.js

• The bootstrap.js file in the config folder feels like a hack. All of the other files in the config folder are simple JSON objects with config settings, but the bootstrap.js file is code that executes at startup
• Some apps need to do several different things at startup, so the bootstrap.js file can quickly become cluttered
• Instead, we will have a “bootstrap” folder. It will work very similar to the “config” folder, in that it can contain any number of files, and SailsJS will automatically run all of those files at startup. This allows for better code organization.
• The signature for bootstrap files can be the same as it is now (a function with a callback param) or we can make it closer to the hooks signature

Add “staging” and “test” environments by default

• These seem like incredibly common ones, so they should exist by default

Move /config/local.js to config/env/local.js

• This is a minor change, but improves consistency
• “local.js” is just a bunch of local overrides for the current environment, so it makes sense to be in the same folder as all the other environment files

Nice-to-Haves:

Upgrade to Node 4.0

• Drop support for Node 0.x
• This should be an easy sell, since Node 4 has an LTS plan, which makes it much more attractive for enterprise-grade server apps
• This also gets us native ES6, without requiring a transpiler

Switch to Promises

• All the places where Sails currently expects callbacks (hooks, bootstraps, middleware, etc.) should support promises
• Promises are the future of async in JavaScript, especially once async/await is fully supported
• We can either drop support for callbacks altogether, or we can support callbacks and promises

Switch to ES6 classes

• All Controllers should inherit from a sails.Controller base class
• All Models should inherit from a sails.Model base class
• All Hooks should inherit from a sails.Hook base class
• ES6 classes make it dead-simple for us to provide base-class functionality that can easily be overridden by developers
• ES6 classes make it dead-simple for developers to conditionally call the base-class (super) implementation, rather than the all-or-nothing approach that Sails currently has
• ES6 classes make it easy for us to provide utility functions & properties via static class members. (ES6 static members are inherited by derived classes)
• ES6 classes give us a well-defined initialization step for each Controller/Model/Hook — the constructor