Adonis 4.0 (Dawn) #19

thetutlage opened this Issue Jan 6, 2017 · 0 comments


None yet

1 participant

thetutlage commented Jan 6, 2017 edited

The newer version of AdonisJs (4.0) named dawn will be a step towards making AdonisJs more approachable, secure, fast and one of the most up to date frameworks in Node.js community.

The issue does not contain all the required changes and will be updated quite frequently with new stuff.


It is really important to understand the ground level goals of AdonisJs from the time when I first started writing it. In software community, we can discuss many aspects which make a framework great or better over each other.

AdonisJs choose to stick to developer joy over any other aspect. That does not mean, we compromise with speed and security, but micro-optimizations are not the goal of the framework. Developer man hours are way too important and costly over adding a new server.

Contribution Practices

Read contributing to AdonisJs

Modular Dependencies

AdonisJs is a combination of several hand-crafted small modules hosted under a Github Organisation called poppinss · GitHub.

The majority of modules are framework agnostic and can be used outside of AdonisJs as well. Below is the list of modules and changes required in them.


  • Add support for async/await based middleware layer.


  • Remove aliases method and let the consumer loop over Objects and call alias for each item in the object.
  • Add support for fakes, Helpful when writing tests and want IOC container to resolve a fake instead of actual value.
  • Remove ** events** except providers:registered and providers:booted. All other events are redundant and come with no use-case.
  • Make register method under ServiceProvider class a plain function, earlier it was an ES2015 generator.
  • Refactor code to make it more simple and well-documented.


  • Re-write cat-log from scratch.
  • Add support for logging outputs. For example: file, console, 3rd party service.
  • Add support for output formats. For example: raw, pretty etc.
  • Never write to console directly and instead of process.stdout stream.
  • Follow RFC 5424 - The Syslog Protocol specs for logging levels

AdonisJs Specific Modules/Providers

Below is the list of modules under adonisjs organization.

adonis-bootstrapper (new)

Adonis bootstrapped is a new library to be written from scratch, which will handle the bootstrap process over starting the server.

  • Add support for lifecycle hooks. For example: onProvidersRegistered, onProvidersBooted, onAppLoaded, onHttpStart, onAceCommand.
  • Expose a nice API to bootstrap the app and abstract all hardcoded logic from bootstrap/http.js and bootstrap/kernel.js.
const bootstrapper = require('adonis-bootstrapper')

// Http server
.register('package.json') // required for application root path and version

// Ace command
.register('package.json') // required for application root path and version

Since all directories are pre-configured in AdonisJs, there is no need to pass any files by hand and bootstrapper will find them using the package.json file.

adonis-translator (new)

Going forward the Service providers can be more powerful and they can have their own pre-built controllers, views, models, etc. which others can use in their app. Which means, there needs to be a bridge between a provider specific modules and user app. Adonis translator is that bridge.

As a user I can do

Route.get('/admin/users', '@Admin:UsersController.index')

As the provider author, I need to bind a directory to be autoloaded under a namespace. These namespaces need to be unique and the best way to keep them unique is to use an identifier like CompanyName/ModuleName. Something followed by Android app.

class MyServiceProvider extends ServiceProvider {
    register () {, '../app', 'Admin')

The directory structure for providers will be same as the app.

NOTE: Autoloading directories inside providers is not a replacement to bindings registered using

Adonis Translator should be able to convert @Admin:<> expressions into proper namespaces, which are then resolved by the IOC Container.

  • Translating Ioc bindings/alias should have no effect. For example:
// returns Adonis/Src/Redis
  • Should be able to translate annotated namespace.
// returns Admin/Model/User
  • Should be able to translate incremental annotated namespace.
// returns Admin/Http/Controllers/UserController


  • Add support for defining Request and Views getters. This will eliminate the need of creating unwanted middleware for every small thing. For example:
class AuthInitMiddleware {
    async handle (request, response, next) {
        const AuthManager = Ioc.use('Adonis/Src/AuthManager')
        request.auth = new AuthManager(request)


// VS

Request.getter('auth', function () {
    const AuthManager = Ioc.use('Adonis/Src/AuthManager')
    return new AuthManager(this)

As you can see creating middleware for decorating request object is redundant and only adding weight to the HTTP request lifecycle. Same can be eliminated with the help of a getter which is evaluated every time a new request comes.

  • Refactoring routes code to make addCollection and addMember stable, as they have some potential issues. Related issue
  • Removing group name from the group method. () {
  • Make static assets resolution a middleware and remove from it the core.
  • Config files can reference each other via @ symbol
module.exports = {
    driver: 'redis',
    redis: '@redis.default'
  • Remove middleware provider from the core and make use of co-compose.
  • Add as method to for prefixing route names. Reference issue

API Docs Design

The API docs are generated using YUIDoc.

  • Get design ready for API docs
  • Built a custom theme to match the given design





Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment