Use $inject as a prop on providers

[nfroidure]

Feature description

Instead of using $.depends which is a function, it is maybe better to use $inject since it is more known and may be more understood.

It will introduce breaking changes.

Use cases

I often end up creating files that exports a function like this which introduce a lot of boilerplate only to allow customizing services/deps name:

module.exports = initDBService;

function initDBService($, name='db', dependencies=['ENV']) {
  return $.service(name, $depends(dbService));
}

function dbService({ ENV }) {
/// actual service code
}

Which is later used like this:

import initDBService from 'db';
import $ from 'knifecycle/instance';

initDBService($);

It would be more concise to do this:

module.exports = dbService;

dbService.$inject = ['ENV'];

function dbService({ ENV }) {
/// actual service code
}

And use it that way:

import dbService from 'db';
import $ from 'knifecycle/instance';

$.service('db', dbService);

// Optionnally change deps
const customDBService = dbService.bind();
customDBService.$inject = ['CONFIG:ENV'];
$.service('customDB', customDBService);

The only con is that some people could forget the bind and this would create some weird behaviors.

• I will do it

[nfroidure]

Just thought that the problem is not in the fact that $.depends is a function but instead that it is tied to a Knifecycle instance which is a non-sense since it could be pure. It would lead to code looking like that:

import depends from 'knifecycle'; // note there are no `/instance`

module.exports = depends(['ENV'], dbService);

function dbService({ ENV }) {
/// actual service code
}

It also solves the bind problem. That said, it worth considering using the $inject property anyway instead of the the current one since it is the de facto standard (used in Angular and Intravenous).

Auto-inject may also be of interest (see sagacity/intravenous#1).