jakehamilton / leverage

🚀 Modularize your application!

Packages

All packages published under the @leverage scope are stored here.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

leverage's Issues

[Feature Request] Make configs optional

This sort of ties in to #19 about reducing boilerplate when writing units. It'd be rather nice to allow certain (possibly all) units to be added without a configuration prop.

With the current system:

/* ... using some Discord plugin ... */

const component = {
  is: 'component',
  config: {
    type: 'discord',
    discord: {
      event: 'message',
    },
  },
  discord: (message) => {},
}

With minimal boilerplate:

/* ... using some Discord plugin ... */

const component = {
  is: 'component',
  type: 'discord',
  discord: (message) => {},
}

If the user's settings would match the plugin's default settings anyway then we can avoid writing extra code.

The only downside to this is that the burden of checking for the existence of configuration on a unit is now up to the author as opposed to Leverage's manager. I hesitate to offer a configRequired option, but that may be the best path forward to allow people to ease into the system.

Plugin identifier callbacks

Support a callback for the identifier option in plugins. Something similar to this:

/* ... */
this.config = {
  type: 'xyz',
  identifier (component) {
    return component.a + '/' + component.b
  }
}
/* ... */

Move types into relevant files instead of the types directory

After playing around a little bit with the location (or generation) of the definition files, I ended up leaving the extra directory (types) there. The types defined in those files should just be moved into the relevant module that actually uses/creates those objects.

The types directory shouldn't have any impact when removed since type definitions are generated and placed in the compiled dist output.

[Feature Request] Allow `type` to be top level on a unit object and make config optional

Sometimes a unit has no need for a config object. As such, forcing the type property to be placed inside of it makes for unnecessary boilerplate. I think we should allow type to be defined directly on the unit like the following:

const component = {
    is: 'component',
    type: 'my-type',
};

This contrasts the current solution:

const component = {
    is: 'component',
    config: {
        type: 'my-type',
    },
};

Finally, there is already precedent for placing an important property directly on the unit. Case in point: Unit.is.

Setup NPM publishing script

Use NPM scripts to setup a publishing step with version bumping, etc.

Remove built-in HTTP server

Leverage has outgrown its original purpose of being solely a HTTP route handler. Any additional pieces (like a HTTP server) should be supplied by plugins.

Transition to TypeScript

Move the project to using TypeScript, including exporting types to be used by developers consuming this module.

Rework dependency system

Rework the dependency system to have a better interface & use either Proxies or Getters.

Redesign for modularity

Redesign the interfaces to be even more decoupled and support a standard interface from which developers can replace pieces at-will.

Documentation

Not just code documentation, also instructional docs on how to use the project, what the interfaces of different modules are, etc.

Create ready-to-use routes/services/middleware

These should be small modules that can be fetched and installed with the CLI tool.

Possibly:

leverage install jakehamilton/leverage-mongoose

[Bug] `Manager.add` not working for paths

Manager crashes with error TypeError: require_dir_all_1.default is not a function when given a path. Apparently this is caused by the 'require-dir-all' module no being imported correctly.

Bad type definitions

Looks like the generated type definition bundle contains some invalid import/export logic. Will need to look through and see what the issue is.

#17 could be rolled into this.

Simplify unit creation

Units (components, middleware, etc.) should be less reliant on extending a class. The idea is to transition to optional class decorators, otherwise the user is required to add a property to their class manually (not difficult).

Example using decorators:

import { Component } from 'leverage-js';

@Component({
    type: 'xyz',
    xyz: {
        option: 'value'
    }
})
class MyComponent {}

new MyComponent();

Example without decorators:

class MyComponent {
    constructor () {
        this.config = {
            // required
            is: 'component',

            type: 'xyz',
            xyz: {
                option: 'value'
            }
        };
    }
}

The idea is that this ends up being simpler than importing a class, extending it, calling super, and then still manually setting the config property.

socket.io integration

Support first party socket.io integration. The feature should be no different than writing a normal route. So far I have come up with a few ways this can be accomplished.

Version 1:

import { Route } from 'leverage-js'

class R extends Route {
  constructor () {
    super()

    this.name = 'socket_index'
    this.socket = {
      event: 'ping',
      /* ... */
    }
  }

  callback (socket, io) {
    socket.emit('pong')
  }
}

Version 2:

import { SocketRoute } from 'leverage-js'

class SR extends SocketRoute {
  constructor () {
    super()

    this.event = 'ping'
  }

  callback (socket, io) {

  }
}

Version 3: (involves modifying api but offers lots of options)

import { Route } from 'leverage-js'

class R extends Route {
  constructor () {
    super()

    this.config = {
      type: ['http', 'socket'],
      path: {
        http: '/',
        socket: 'ping'
      }
    }
  }

  http (req, res) {
    res.send(200)
  }

  socket (socket, io) {
    socket.emit('pong')
  }
}

I like version 3 the most currently with its possibilities. Future-proofing a little bit by designing a system for including new types. New things can be patched in by other packages which would be nice for decentralization.

Consider more generic names

Consider using names like manager and component instead of router and route. This would make things easier to understand when developing software that does not mirror something like a http server.

Test v1.0.0

Test version 1.0.0 when it is feature complete.

Create better middleware system

Convert middleware to a system similar to services, where we can hot-patch the server and maybe even router.

Typo

It says area instead of just are

Leverage CLI tool

Create a CLI tool that can be used to easily create a new project with a skeleton "Leverage" structure. Additionally, allow homebrew routes/services/middleware to be installed quickly via this tool.

Have someone make a super sweet logo