GithubHelp home page GithubHelp logo

owja / ioc Goto Github PK

View Code? Open in Web Editor NEW
275.0 5.0 12.0 1.08 MB

:unicorn: lightweight (<1kb) inversion of control javascript library for dependency injection written in typescript

License: MIT License

JavaScript 2.45% TypeScript 97.55%
ioc ioc-container inversion-of-control dependency-injection javascript typescript dependency-inversion services decorators lightweight

ioc's Introduction

@owja/ioc

npm version npm version size CircleCI npm

This library implements dependency injection for javascript and typescript.

Features

  • Similar syntax to InversifyJS
  • Can be used without decorators
  • Less Features but straight forward
  • Can bind dependencies as classes, factories and static values and provide dependencie arguments or parameters if needed
  • Supports binding in singleton scope
  • Cached - Resolves only once in each dependent class by default
  • Cache can switched off directly at the inject decorator
  • Made with unit testing in mind
  • Supports dependency rebinding and container snapshots and restores
  • Lightweight - Below 1kb brotli/gzip compressed
  • Does NOT need reflect-metadata which size is around 50 kb
  • 100% written in Typescript

Install

npm install --save-dev @owja/ioc

Latest preview/dev version (alpha or beta)

npm install --save-dev @owja/ioc@next

The Container API

Creating a container

The container is the place where all dependencies get bound to. It is possible to have multiple container in our project in parallel.

import {Container} from "@owja/ioc";
const container = new Container();

Binding

Binding a class

This is the default way to bind a dependency. The class will get instantiated when the dependency gets resolved. You will be able to pass down it's dependencie arguments once you resolve it.

container.bind<ServiceInterface>(symbol).to(Service);

Binding a class in singleton scope

This will create only one instance of Service

container.bind<ServiceInterface>(symbol).to(Service).inSingletonScope();

Binding a factory

Factories are functions which will get called when the dependency gets resolved

container.bind<ServiceInterface>(symbol).toFactory(() => new Service());
container.bind<string>(symbol).toFactory(() => "just a string");
container.bind<string>(symbol).toFactory((a: string) => `I need a string parameter: ${a}`);

A factory can configured for singleton scope too. This way will only executed once.

container.bind<ServiceInterface>(symbol).toFactory(() => new Service()).inSingletonScope();

Binding a value

This is always like singleton scope, but it should be avoid to instantiate dependencies here. If they are circular dependencies, they will fail.

container.bind<ServiceInterface>(symbol).toValue(new Service()); // Bad, should be avoid
container.bind<string>(symbol).toValue("just a string");
container.bind<() => string>(symbol).toValue(() => "i am a function");

Rebinding

This is the way how we can rebind a dependency while unit tests. We should not need to rebind in production code.

container.rebind<ServiceMock>(symbol).toValue(new ServiceMock());

Removing

Normally this function is not used in production code. This will remove the dependency from the container.

container.remove(symbol);

Getting a dependency

Getting dependencies without @inject decorators trough container.get() is only meant for unit tests. This is also the internal way how the @inject decorator and the functions wire() and resolve() are getting the dependency.

container.get<Interface>(symbol);

To get a dependency without @inject decorator in production code use wire() or resolve(). Using container.get() directly to getting dependencies can result in infinite loops with circular dependencies when called inside of constructors. In addition container.get() does not respect the cache.

Important Note: You should avoid accessing the dependencies from any constructor. With circular dependencies this can result in a infinite loop.

Snapshot & Restore

This creates a snapshot of the bound dependencies. After this we can rebind dependencies and can restore it back to its old state after we made some unit tests.

container.snapshot();
container.restore();

The inject Decorator

To use the decorator you have to set experimentalDecorators to true in your tsconfig.json.

First we have to create a inject decorator for each container:

import {createDecorator} from "@owja/ioc";
export const inject = createDecorator(container);

Then we can use the decorator to inject the dependency.

class Example {
    @inject(symbol/*, [tags], ...dependencie arguments*/)
    readonly service!: Interface;
    
    method() {
        this.service.doSomething();
    }
}

The wire() Function

If we do not want to use decorators, we can use the wire function. It does the same like the inject decorator and we have to create the function first like we do with inject.

import {createWire} from "@owja/ioc";
export const wire = createWire(container);

Then we can wire up the dependent to the dependency.

class Example {
    readonly service!: Interface;
    
    constructor() {
        wire(this, "service", symbol/*, [tags], ...dependencie arguments*/);
    }
    
    method() {
        this.service.doSomething();
    }
}

Notice: With wire() the property, in this case service, has to be public.

The resolve() Function

A second way to resolve a dependency without decorators is to use resolve(). To use resolve() we have to create the function first.

import {createResolve} from "@owja/ioc";
export const resolve = createResolve(container);

Then we can resolve the dependency in classes and even functions.

class Example {
    private readonly service = resolve<Interface>(symbol);
    
    method() {
        this.service(/*...dependencie arguments*/).doSomething();
    }
}
function Example() {
    const service = resolve<Interface>(symbol);
    service(/*...dependencie arguments*/).doSomething();
}

Notice: We access the dependency trough a function. The dependency is not assigned directly to the property/constant. If we want direct access we can use container.get() but we should avoid using get() inside of classes because we then loose the lazy dependency resolving/injection behavior and caching.

The symbol

Symbols are used to identify our dependencies. A good practice is to keep them in one place.

export const TYPE = {
    "Service" = Symbol("Service"),
    // [...]
}

Symbols can be defined with Symbol.for() too. This way they are not unique. Remember Symbol('foo') === Symbol('foo') is false but Symbol.for('foo') === Symbol.for('foo') is true

export const TYPE = {
    "Service" = Symbol.for("Service"),
    // [...]
}

Since 1.0.0-beta.3 we use the symbol itself for indexing the dependencies. Prior to this version we indexed the dependencies by the string of the symbol.

πŸ†• Type-Safe Token (new in 2.0)

With version 2 we added the possibility to use a type-safe way to identify our dependencies. This is done with tokens:

export TYPE = {
    "Service" = token<MyServiceInterface>("Service"),
    // [...]
}

In this case the type MyServiceInterface is inherited when using container.get(TYPE.Service), resolve(TYPE.Service) and wire(this, "service", TYPE.Service)and does not need to be explicitly added. In case of the decorator @inject(TYPE.Service) it needs to be added but it throws a type error if the types don't match:

class Example {
    @inject(TYPE.Service/*, [tags], ...dependencie arguments*/) // throws a type error because WrongInterface is not compatible with MyServiceInterface
    readonly service!: WrongInterface;
}

Correkt:

class Example {
    @inject(TYPE.Service/*, [tags], ...dependencie arguments*/)
    readonly service!: MyServiceInterface;
}

πŸ†• Plugins (new in 2.0)

Plugins are a way to hook into the dependency resolving process and execute code which can access the dependency and also the dependent object.

A plugin can add directly to a dependency or to the container.

container.bind(symbol).to(MyService).withPlugin(plugin);
container.addPlugin(plugin);

The plugin is a simple function which has access to the dependency, the target (the instance which requires the dependency), the arguments which are passed, the token or symbol which represents the dependency and the container.

type Plugin<Dependency = unknown> = (
    dependency: Dependency,
    target: unknown,
    args: symbol[],
    token: MaybeToken<Dependency>,
    container: Container,
) => void;

Plugin Example

The following code is a plugin which links a preact view component to a service by calling forceUpdate every time the service executes the listener:

import {Plugin} from "@owja/ioc";
import {Component} from "preact";

export const SUBSCRIBE = Symbol();

export const serviceListenerPlugin: Plugin<Listenable> = (service, component, args) => {
    if (args.indexOf(SUBSCRIBE) === -1 || !component) return;
    if (!isComponent(component)) return;

    const unsubscribe = service.listen(() => component.forceUpdate());
    const unmount = component.componentWillUnmount;

    component.componentWillUnmount = () => {
        unsubscribe();
        unmount?.();
    };
};

function isComponent(target: unknown) : target is Component {
    return  !!target && typeof target === "object" && "forceUpdate" in target;
}

interface Listenable {
    listen(listener: () => void): () => void;
}

Note: this will fail on runtime if service does not implement the Listenable interface because there is no type checking done

This plugin is added to the dependency directly:

const TYPE = {
    TranslationService: token<TranslatorInterface>("translation-service"),
};

container
    .bind<TranslatorInterface>(TYPE.TranslationService)
    .toFactory(translationFactory)
    .inSingletonScope()
    .withPlugin(serviceListenerPlugin);

In a component it is then executed when the dependency is resolved:

class Index extends Component {
    @inject(TYPE.TranslationService, [SUBSCRIBE]/*, ...dependencie arguments*/)
    readonly service!: TranslatorInterface;

    render() {
        return (
            <div>{this.service.t("greeting")}</div>
        );
    }
}

This works also with wire and resolve:

class Index extends Component {
    readonly service!: TranslatorInterface;

    constructor() {
        super();
        wire(this, "service", TYPE.TranslationService, [SUBSCRIBE]/*, ...dependencie arguments*/);
    }
    
    [...]
}

class Index extends Component {
    readonly service = resolve(TYPE.TranslationService, [SUBSCRIBE]/*, ...dependencie arguments*/);
    
    [...]
}

Prevent Plugins from Execution

In case you add a plugin it is executed every time the dependency is resolved. If you want to prevent this you can add the NOPLUGINS tag to the arguments:

import {NOPLUGINS} from "@owja/ioc";

class Example {
    @inject(TYPE.MyService, [NOPLUGINS]/*, ...dependencie arguments*/)
    readonly service!: MyServiceInterface;
}

Getting Started

Step 1 - Installing the OWJA! IoC library

npm install --save-dev @owja/ioc

Step 2 - Creating symbols for our dependencies

Now we create the folder services and add the new file services/types.ts:

export const TYPE = {
    MyService: Symbol("MyService"),
    MyOtherService: Symbol("MyOtherService"),
};

Step 3 - Example services

Next we create out example services.

File services/my-service.ts

export interface MyServiceInterface {
    hello: string;
}

export class MyService implements MyServiceInterface{
    hello = "world";
}

File services/my-other-service.ts

export interface MyOtherServiceInterface {
    random: number;
}

export class MyOtherService implements MyOtherServiceInterface {
    random = Math.random();
}

Step 4 - Creating a container

Next we need a container to bind our dependencies to. Let's create the file services/container.ts

import {Container, createDecorator} from "@owja/ioc";

import {TYPE} from "./types";

import {MyServiceInterface, MyService} from "./service/my-service";
import {MyOtherServiceInterface, MyOtherService} from "./service/my-other-service";

const container = new Container();
const inject = createDecorator(container);

container.bind<MyServiceInterface>(TYPE.MyService).to(MyService);
container.bind<MyOtherServiceInterface>(TYPE.MyOtherService).to(MyOtherService);

export {container, TYPE, inject};

Step 5 - Injecting dependencies

Lets create a example.ts file in our source root:

import {TYPE, inject} from "./service/container";
import {MyServiceInterface} from "./service/my-service";
import {MyOtherServiceInterface} from "./service/my-other-service";

class Example {
    @inject(TYPE.MyService/*, [tags], ...dependencie arguments*/)
    readonly myService!: MyServiceInterface;

    @inject(TYPE.MyOtherService/*, [tags], ...dependencie arguments*/)
    readonly myOtherService!: MyOtherServiceInterface;
}

const example = new Example();

console.log(example.myService);
console.log(example.myOtherService);
console.log(example.myOtherService);

If we run this example we should see the content of our example services.

The dependencies (services) will injected on the first call. This means if you rebind the service after accessing the properties of the Example class, it will not resolve a new service. If you want a new service each time you call example.myService you have to add the NOCACHE tag:

// [...]
import {NOCACHE} from "@owja/ioc";

class Example {
    // [...]
    
    @inject(TYPE.MyOtherSerice, NOCACHE/*, ...dependencie arguments*/)
    readonly myOtherService!: MyOtherServiceInterface;
}

// [...]

In this case the last two console.log() outputs should show different numbers.

Unit testing with IoC

For unit testing we first create our mocks

test/my-service-mock.ts

import {MyServiceInterface} from "../service/my-service";

export class MyServiceMock implements MyServiceInterface {
    hello = "test";    
}

test/my-other-service-mock.ts

import {MyOtherServiceInterface} from "../service/my-other-service";

export class MyOtherServiceMock implements MyOtherServiceInterface {
    random = 9;
}

Within the tests we can snapshot and restore a container. We are able to make multiple snapshots in a row too.

File example.test.ts

import {container, TYPE} from "./service/container";
import {MyServiceInterface} from "./service/my-service";
import {MyOtherServiceInterface} from "./service/my-other-service";

import {MyServiceMock} from "./test/my-service-mock";
import {MyOtherServiceMock} from "./test/my-other-service-mock";

import {Example} from "./example";

describe("Example", () => {
    
    let example: Example;
    beforeEach(() => {
        container.snapshot();
        container.rebind<MyServiceInterface>(TYPE.MyService).to(MyServiceMock);
        container.rebind<MyOtherServiceInterface>(TYPE.MyOtherService).to(MyOtherServiceMock);

        example = new Example();
    });

    afterEach(() => {
        container.restore();
    });

    test("should return \"test\"", () => {
        expect(example.myService.hello).toBe("test");
    });

    test("should return \"9\"", () => {
        expect(example.myOtherService.random).toBe(9);
    });
    
});

Development

Current state of development can be seen in our Github Projects.

Inspiration

This library is highly inspired by InversifyJS but has other goals:

  1. Make the library very lightweight (less than one kilobyte)
  2. Implementing less features to make the API more straight forward
  3. Always lazy inject the dependencies
  4. No meta-reflect required

License

MIT

Copyright Β© 2019-2022 The OWJA! Team

ioc's People

Contributors

greenkeeper[bot] avatar hbroer avatar ksaxberg avatar lorefnon avatar vic1707 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

ioc's Issues

An in-range update of @typescript-eslint/eslint-plugin is breaking the build 🚨

The devDependency @typescript-eslint/eslint-plugin was updated from 1.9.0 to 1.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@typescript-eslint/eslint-plugin is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of eslint-plugin-jest is breaking the build 🚨

The devDependency eslint-plugin-jest was updated from 22.5.1 to 22.6.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

Release Notes for v22.6.0

22.6.0 (2019-05-22)

Features

Commits

The new version differs by 9 commits.

  • 14d83ef feat(rules): add no-commented-out rule (#262)
  • 83ff198 chore: migrate no-jest-import to typescript (#259)
  • 718c08c chore: upgrade @typescript-eslint
  • ca2aa27 chore: port lowercase-name to TypeScript (#258)
  • 3df0058 chore(ci): run danger with lts version of node
  • 48e3a59 chore: precompile with babel (#257)
  • 8670804 chore: bump deps
  • 05eb11a chore: fix lint error
  • dff6446 docs: link to eslint-plugin-jest-formatting

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Dynamically reload injection

Hello,

First of all, I want to thank you for your awesome project !

I'm currently using the version 2.0.0-alpha.3 on a REACT game project.

For my project I would like to be able to test multiple JSX versions of the same component on the fly.

I'd like for all my components to come with a SVG version, a WebGL and canvas one.
For this issue I assumed I have two redering method svg and svg2 (canvas and webGL cause issues due to useEffect being used).

I have the logic for my component in a vanilla class and injected render method based on a token.

I think (and hope) the code is kinda self explanatory.

Here are the files I use for now

  • container.ts containing tokens for the rendering methods.
export type renderingMethods = 'canvas' | 'svg' | 'svg2' | 'webGL';

const container = new Container();
export const resolve = createResolve(container);
export const get = container.get;

export const RENDERERS: { [K in renderingMethods]: Token<FunctionComponent<Props>> } = {
  canvas: token('canvas'),
  svg: token('svg'),
  svg2: token('svg2'),
  webGL: token('webGL')
};

container.bind(RENDERERS.canvas).toValue(BoardCanvas);
container.bind(RENDERERS.svg).toValue(BoardSVG);
container.bind(RENDERERS.svg2).toValue(BoardSVG2);
container.bind(RENDERERS.webGL).toValue(BoardWebGL);
  • App.tsx with a select in the header to choose the rendering method.
function App() {
  const board = new Board({ x: 200, y: 200 });
  const [renderer, setRenderer] = useState<renderingMethods>('svg');

  return (
    <>
      <header>
        <label>
          Rendering Method
          <br />
          <select value={renderer} onChange={({ target: { value } }) => setRenderer(value as renderingMethods)}>
            <option value="canvas">Canvas</option>
            <option value="svg">SVG</option>
            <option value="svg2">SVG2</option>
            <option value="webGL">WebGL</option>
          </select>
        </label>
        {renderer}
      </header>
      <div className="App">{board.render(renderer)}</div>
    </>
  );
}
  • Board.ts
export class Board implements board {
  bounds: BoardRanges;

  constructor(bounds: BoardRanges) {
    this.bounds = {
      x: Math.abs(bounds.x),
      y: Math.abs(bounds.y)
    };
  }

  readonly render = (renderer: renderingMethods) => resolve(RENDERERS[renderer])()({ bounds: this.bounds });
}
  • the svg renderer
export const BoardSVG: FunctionComponent<Props> = ({ bounds }: Props) => {
  console.log('using board svg');
  return (
    <svg width={bounds.x} height={bounds.y} className="game-board">
      <g transform={`matrix(1 0 0 -1 ${bounds.x / 2} ${bounds.y / 2})`}>
        <line x1={-bounds.x / 2} x2={bounds.x / 2} strokeWidth="1px" stroke="#000" />
        <line y1={-bounds.y / 2} y2={bounds.y / 2} strokeWidth="1px" stroke="#000" />
      </g>
    </svg>
  );
};
  • the svg2 renderer
export const BoardSVG2: FunctionComponent<Props> = ({ bounds }: Props) => {
  console.log('using board svg2');
  return (
    <svg width={bounds.x} height={bounds.y} className="game-board">
      <g transform={`matrix(1 0 0 -1 ${bounds.x / 2} ${bounds.y / 2})`}>
        <line x1={-bounds.x / 2} x2={bounds.x / 2} strokeWidth="1px" stroke="#333" />
        <line y1={-bounds.y / 2} y2={bounds.y / 2} strokeWidth="1px" stroke="#333" />
      </g>
    </svg>
  );
};

the UI/injection doesn't seem to reload as it always giving me the console.log('using board svg'); output.

I'm not really sure if it's a problem with the lib or with me not doing things correctly

`toValue` consider function given as a factory.

Describe the bug
The Container.bind(...).toValue(...) consider the a given function as a fatory.

To Reproduce

import { Container, token } from "@owja/ioc"
const TYPE = {
  myType: token("MyType")
}
const container = new Container()
container.bind(TYPE.myType).toValue((text) => {
  if (text === undefined) console.log("You cannot give undefined.")
  else console.log(text)
})
const myFunc = container.get(TYPE.myType)
myFunc("hello, world!")

the console output is

You cannot give undefined.
file:///test.js:11
myFunc("hello, world!")
^

TypeError: myFunc is not a function

Expected behavior
I want to bind a Getter function, such as (options) => create(options) with toValue, however, the container considered it as a factory and tried to call it and retrieved the return value.

I don't think toValue() should detect its type under the hood, which made me confused.
Instead, toFactory() is more suitable for this.

Environment (please complete the following information):

  • typescript^4.9.5
  • Node v16.18.0
  • ^2.0.0-alpha.6

Additional context
The workaround is to wrap the function with a new function.

container.bind(TYPE.myType).toValue(() => (text) => {
  if (text === undefined) console.log("You cannot give undefined.")
  else console.log(text)
})

But it makes the typing sucks in typescript.
Because the token should be token<()=>(text:string)=>void>("MyType"), then the return value from container.get(...) is typed by ()=>(text:string)=>void but (text:string)=>void is actually expected.

Testing & Code Reviews

I could need some help with testing and some people doing code review of my own work. Feel free to open Issue, make pull requests or just comment here. :)

Example Repository

create a new repository with examples

  • ...for javascript
  • ...for typescript

Performance Enhancement

  • get the dependency from the container only once
  • listen on rebinds to delete the cached dependency so it will reresolved on next get

An in-range update of eslint-plugin-jest is breaking the build 🚨

The devDependency eslint-plugin-jest was updated from 22.9.0 to 22.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

Release Notes for v22.10.0

22.10.0 (2019-07-17)

Features

Commits

The new version differs by 7 commits.

  • 28bd1dc feat(rules): adds no-if rule (#293)
  • 7ebdc0e chore: enforce import destructure order
  • 31c7cef chore: convert to import/export (#302)
  • 9f858cb chore: delete tests instead of ignoring them with babel
  • c595ba0 chore: do not include tests in published tarball
  • 4b4eb78 chore: fix lint error in md file
  • d3ea720 chore(docs): fix typo (#304)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

1.0.0 Release

  • Check Documentation if everything is correct
  • Remove the beta "unstable" info from documentation
  • Set package.json version to 1.0.0
  • Tag and deploy to npm

Maybe container has an implicit behavior

Hi, first of all thanks for pretty good library.

I noticed that container can have an implicit behaviour.

According to api, i can bind service to symbol and save options to the variable.
Later I can start get services from the container by symbol.
But after that I can use options to change type of service by options.toSingletonScope()

After changing service type I will receive only one instance.

I don't know, maybe it is a regular behaviour but it can confuse the developer.

Maybe I'm wrong and this behaviour implies that at the time of binding, the developer may not know what the service should be.

P.S. Sorry for bug label...

Release 1.0.0-beta.0

  • deploy with travis to npmjs no automatic deployment at the moment
  • Check example implementation
  • Update documentation

An in-range update of @typescript-eslint/parser is breaking the build 🚨

The devDependency @typescript-eslint/parser was updated from 2.7.0 to 2.8.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@typescript-eslint/parser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

Release Notes for v2.8.0

2.8.0 (2019-11-18)

Bug Fixes

  • eslint-plugin: [camelcase] handle optional member expr (#1204) (9c8203f)
  • eslint-plugin: [indent] fix decorator type (#1189) (e2008e3)
  • eslint-plugin: [indent] handle empty generic declarations (#1211) (9aee06c)
  • eslint-plugin: [no-type-alias] handle constructor aliases (#1198) (1bb4d63)
  • eslint-plugin: [no-unnec-type-arg] throwing on call/new expr (#1217) (42a48de)
  • eslint-plugin: [no-unnecessary-cond] fix naked type param (#1207) (4fac6c5)
  • eslint-plugin: [nuta] correctly handle null/undefined separation (#1201) (9829dd3)
  • eslint-plugin: [require-await] better handle nesting (#1193) (eb83af1)
  • eslint-plugin: [unified-signatures] crash: cannot read pro… (#1096) (d1de3a7)
  • eslint-plugin: disable base no-unused-expressions in all config (ecb3f4e)
  • typescript-estree: correctly account for trailing slash in… (#1205) (ba89168)
  • typescript-estree: options range loc being always true (#704) (db1aa18)

Features

  • eslint-plugin: [no-type-alias] handle conditional types (#953) (259ff20)
  • eslint-plugin: add rule restrict-template-expressions (#850) (46b58b4)
  • eslint-plugin: add space-before-function-paren [extension] (#924) (d8b07a7)
  • eslint-plugin: added new rule no-dynamic-delete (#565) (864c811)
  • eslint-plugin: added new rule no-untyped-public-signature (#801) (c5835f3)
Commits

The new version differs by 20 commits.

  • a9117f5 chore: publish v2.8.0
  • 46b58b4 feat(eslint-plugin): add rule restrict-template-expressions (#850)
  • 42a48de fix(eslint-plugin): [no-unnec-type-arg] throwing on call/new expr (#1217)
  • ba89168 fix(typescript-estree): correctly account for trailing slash in… (#1205)
  • eb83af1 fix(eslint-plugin): [require-await] better handle nesting (#1193)
  • 9829dd3 fix(eslint-plugin): [nuta] correctly handle null/undefined separation (#1201)
  • d1de3a7 fix(eslint-plugin): [unified-signatures] crash: cannot read pro… (#1096)
  • 9aee06c fix(eslint-plugin): [indent] handle empty generic declarations (#1211)
  • 74192f8 chore: bump dependencies (#1208)
  • e2008e3 fix(eslint-plugin): [indent] fix decorator type (#1189)
  • 4fac6c5 fix(eslint-plugin): [no-unnecessary-cond] fix naked type param (#1207)
  • 259ff20 feat(eslint-plugin): [no-type-alias] handle conditional types (#953)
  • 9c8203f fix(eslint-plugin): [camelcase] handle optional member expr (#1204)
  • d8b07a7 feat(eslint-plugin): add space-before-function-paren [extension] (#924)
  • ca41dcf docs(eslint-plugin): brace-style as a replacement for one-line (#1202)

There are 20 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Inline Documentation

People suggested to add some inline documentation because they have problems to understand how the library works. This should be fixed.

An in-range update of @types/jest is breaking the build 🚨

The devDependency @types/jest was updated from 24.0.19 to 24.0.20.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @typescript-eslint/eslint-plugin is breaking the build 🚨

The devDependency @typescript-eslint/eslint-plugin was updated from 2.10.0 to 2.11.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@typescript-eslint/eslint-plugin is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

Release Notes for v2.11.0

2.11.0 (2019-12-09)

Bug Fixes

  • eslint-plugin: [brace-style] handle enum declarations (#1281) (3ddf1a2)

Features

  • eslint-plugin: [member-ordering] add index signature (#1190) (b5a52a3)
Commits

The new version differs by 6 commits.

  • 9f76095 chore: publish v2.11.0
  • 324f155 docs(eslint-plugin): ROADMAP note some jsdoc rules (#1319)
  • 3ddf1a2 fix(eslint-plugin): [brace-style] handle enum declarations (#1281)
  • b5a52a3 feat(eslint-plugin): [member-ordering] add index signature (#1190)
  • 39f654b test(eslint-plugin): [unified-signatures] add tests for #740 (#1074)
  • 5362561 docs(eslint-plugin): typo in space-before-function-paren docs (#1297)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

wire/inject/resolve strictly binds service to specific container

Hi, i use @owja/ioc in Node.js app.

In my app i have a service (for example named MyService) that has one dependency.

I use wire function for define dependency.

In my case i have two containers in two apps and i want to use MyService in both of containers

But the wire function is created for a specific container strictly binds each service to the container.

In my case i act like this:

const createMyService = wire => class MyService {
  constructor () {
    wire(this, 'myDependency', TYPE.myDependency)
  }
};

But it looks more like a trick.

How can i properly create service for use it in any container?

Singelton Scope

Make it possible to bind in in singleton scope.

  • .to().inSingeltonScope()
  • .toFactory().inSingeltonScope()

.toValue() is not affected.

Async construction?

Hey, I might need to download a bundle containing a service when resolving it so I need a way to .get asynchronously and have async factories (like in InversifyJS for example).

Alternatively if plugins could return a Promise I guess that would also work for this use case.

Idea for the docs?

This is how I personally like to use this library in my project:

import {Container} from "@owja/ioc";
const container = new Container();

const BAR = Symbol.for("bar")
const FOO = Symbol.for("foo")

interface Foo {
  doThing(): void
  tellBarToDoThing(): void 
}

class AppFoo implements Foo {
  constructor(private bar: Bar = container.get(BAR)) {}

  doThing(): void {
    console.log('foo do thing')
  }

  tellBarToDoThing() {
    this.bar.doThing()
  }
}

container.bind<Foo>(FOO).to(AppFoo)
interface Bar {
  doThing(): void 
  tellFooToDoThing(): void
}

class AppBar implements Bar {
  constructor(private foo: Foo = container.get(FOO)) {}
  doThing() {
    console.log('bar do thing')
  }

  tellFooToDoThing() {
    this.foo.doThing()
  }
}

// You don't need to use `toFactory()` below, but here just for example sake. 
container.bind<Bar>(BAR).toFactory(() => { return new AppBar() }).inSingletonScope() 

let foo: Foo = container.get(FOO)
foo.doThing()

let bar: Bar = container.get(BAR)
bar.doThing()

The code to look at here is the constructors of the classes. This is how I like to resolve the dependencies for my classes instead of wire() or resolve() that the readme suggests.

Wanted to see what you thought. Do you see anything wrong with this? Do you see it as a value add to add this technique to the readme as another option to resolving dependencies?

An in-range update of @typescript-eslint/parser is breaking the build 🚨

The devDependency @typescript-eslint/parser was updated from 1.9.0 to 1.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@typescript-eslint/parser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

possibility to hook into `container.get()` (plugin)

a simple plugin functionality could fix some needs to get rid of some boilerplate code if for example a service should trigger a listener, subscribe and unsubscribe automatically on mount and unmount of components. Plugins are more versatile and easier to adapt than application specific code.

This is a replacement for #22

Inject a service that requires constructor arguments ?

Id like to be able to inject a class that requires arguments for it's constructor which would give more flexibility for some use cases.

Describe the solution you'd like
I think a rework of the Factory type could do the trick, for now it doesn't accept any parameters πŸ€”
the idea, if possible, would be to usesomething like this
container.bind(<symbol>).toFactory( (...args: InjectedConstructorArgs) => new Injected(...args)) )
and then
resolveContainer(<symbol>)(...args)

Describe alternatives you've considered
put the constructor logic in another function that is called manually after injection

Cache None-Singletons

Is your feature request something you would just nice to see implemented?
It would be nice if a dependency which got injected will not resolve on every call on the propery which resolves the dependency. It would be nice too if this behavior can be configured.

Describe the solution you'd like
I am not shure which solution i wuld prefer. For myself i normaly use dependencies in singelton scope. But sometimes it could be usefull to resolve a dependency only once per instance. And this feature will improof performance too if caching is the default behavior.

Question

Which implementation whould you prefer? Or keep the current state? Or any other suggestion?

Examples have bugs

The README.md has to be checked. There is at least one error.

export const TYPE = {
    "MyService" = Symbol("MyService"),
    "MyOtherService" = Symbol("MyOtherService"),
};

should be

export const TYPE = {
    MyService: Symbol("MyService"),
    MyOtherService: Symbol("MyOtherService"),
};

An in-range update of eslint-plugin-jest is breaking the build 🚨

The devDependency eslint-plugin-jest was updated from 22.6.1 to 22.6.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Release Notes for v22.6.2

22.6.2 (2019-05-22)

Bug Fixes

  • move @typescript-eslint/experimental-utils to dependencies (#267) (331457d)
Commits

The new version differs by 1 commits.

  • 331457d fix: move @typescript-eslint/experimental-utils to dependencies (#267)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.