kindergouello / netero

Framework agnostic dependency injection library

Hi !

I'm Rémy, a Freelance Developer living in Paris

---

Open source projects

• netero - Framework agnostic dependency injection library in Typescript

Languages and tools

Github stats

netero's Issues

Multiple classes by file

Describe the solution you'd like
If you have multiple class definitions by file, currently, you will only be able to inject the first class found in that file.
Having a option class in the configuration file allows you to have multiple classes in the same file and declare these classes independently in the configuration.
See:

// multipleClasses.ts
export class Bar {
  private name: string;

  constructor(name: string) {
    this.name = name;
  }

  getName() {
    return this.name;
  }
}
export class Foo {
  private name: string;

  constructor(name: string) {
    this.name = name;
  }

  getName() {
    return this.name;
  }
}

services:
  foo:
    path: "multipleClasses"
    class: "Foo"
    arguments:
      - "Foo name"
  bar:
    path: "multipleClasses"
    class: "Bar"
    arguments:
      - "Bar name"

Describe alternatives you've considered
You could also declare only one class by file.

Add tag support

Describe the solution you'd like
There are some times where you want to inject automatically some new classes of a same context as a dependency.
For example, you want to inject multiple map API providers into a class to iterate through them:

class Map {
  constructor(providers: MapProvider[]) { ... }

  findAllPathEstimations() {
    this.providers.map(...)
  }
}

So you will have a configuration like this:

services:
  gmap:
    ...
  citymapper:
    ...
  here:
    ...
  map:
    arguments:
      - ['@gmap', '@citymapper', '@here']
      ...

This works, but maybe you want to add new providers one day or use this array of map providers for a different use case.
With a tag option, you will be able to gather these services into a common group. Then, this group can be provided as an argument and every service with the same tag will be dynamically added to it:

services:
  gmap:
    ...
    tags: ['map']
  citymapper:
    ...
    tags: ['map']
  here:
    ...
    tags: ['map']
  map:
    arguments:
      - '#map'
      ...

The # prefix is dedicated to identifying tag arguments. You can, of course, add multiple tags to a service.

Change alias in configuration file

The current way of writing the configuration doesn't allow so much flexibility for the refactoring or to change file namespace. For example with a configuration like this one:

parameters:
  mailer.transport: sendmail
services:
  Mailer:
    arguments:
      - "%mailer.transport%"
  NewsletterManager:
    arguments:
      - "@Mailer"

the Mailer and NewsletterManager services are supposed to be in the root of the project, ./Mailer and ./NewsletterManager. If we want to move them into a directory of subdirectory, let's say, folder, then the configuration file should be like:

parameters:
  mailer.transport: sendmail
services:
  "folder/Mailer":
    arguments:
      - "%mailer.transport%"
  "folder/NewsletterManager":
    arguments:
      - "@folder.Mailer"

It means that, since the alias of the Mailer class changed, then the NewsletterManager definition should be updated as well to require a service from a valid alias.

So, with a path options required and an alias not auto-generated, you can have much more flexibility to reorganize your code without updating other dependencies.
Here is what it will look like:

parameters:
  mailer.transport: sendmail
services:
  mailer: # name chosen by yourself (could be) some.thing.mailer
    path: "folder/Mailer",
    arguments:
      - "%mailer.transport%"
  newsletterManager:
    path: "folder/NewsletterManager",
    arguments:
      - "@mailer"

If you move your Mailer class in another directory, then you will only need to update the path of the Mailer definition.

You will also be able to declare multiple instances of the same class. Let's say you want different Mailer instances that use different kind of transport. The configuration will be:

parameters:
  mailer.transport: sendmail
services:
  mailer.basic:
    path: "folder/Mailer",
    arguments:
      - "%mailer.transport%"
  mailer.amazon:
    path: "folder/Mailer",
    arguments:
      - "amazon"
  newsletterManager:
    path: "folder/NewsletterManager",
    arguments:
      - "@mailer.amazon"

Configure command to automate a release

See https://github.com/tool3/bump to bump the package.json version according to the release
And https://hackernoon.com/publish-npm-packages-using-github-actions-a-how-to-guide-q31c34fg to publish to npm
Or https://michaelzanggl.com/articles/github-actions-cd-setup/