Move instantiation system to a separate package for use by third parties

[joelday]

VSCode's instantiation/dependency management system seems useful and has low boilerplate. Would be nice to use elsewhere.

[jrieken]

@joelday You mean InstantiationService and the decoration mechanism?

[joelday]

Yup!

[joelday]

@jrieken I can take an unofficial stab at this. If that's alright, what would be an ideal package name?

[jrieken]

Naming is a hard problem... It is some DI system using constructor injections - maybe something along those lines. About how to tackle this, I'd recommend to start with copying out the current system and making the adoption a second step. That is because large cross cutting PRs are hard to get merged unless we know what's coming ;-)

[joelday]

@jrieken Just did an initial pass on this: https://github.com/joelday/vscode-instantiation. It's enough to start using for my purposes.

I removed the async instantiation support for the time being. Let me know if I should tweak anything in the readme, license, etc.

Thank you!

[jrieken]

The most important are ✔️ License and ✔️ Copyright notes which look good. Since this module isn't exclusive for VS Code I'd go for a better name - also it might avoid confusion around the topic. Maybe something like decorator-ioc or _decoratordi?

[jrieken]

@egamma fyi

[joelday]

Changed the name on GitHub and NPM to decorator-ioc.

If anyone with detailed familiarity with the framework can to contribute to docs, I've opened this for editing: https://github.com/joelday/decoration-ioc/wiki

Thanks, everyone!

[jrieken]

I can write some doc but it'll take me a few days until I get to it - we are approaching end of milestone and my list is still long 🙈

[joelday]

@jrieken Nobody even knows about this thing yet. I think it can wait. I'll get started soon, too. :)

[joelday]

Just added member/property injection, btw.

[remojansen]

I just discovered this module, it has quite interesting style of DI :smile: . I've been working for over a year on InversifyJS, if you are interested in IoC containers in TS you will find it interesting :wink:

[joelday]

@remojansen Cool. :)

@jrieken I've been looking through everything and haven't seen many cases where _serviceBrand is used at all. I see a few spots where it is specified, but I'm not seeing any places where it is used either explicitly or for type validation or inference. Anything I'm missing?

[jrieken]

seen many cases where _serviceBrand is used at all.

It's only used for type checking and there to break structural typing. Look at these IConstructorSignature definitions. We basically want to express that an object can be instantiated by arbitrary parameter followed by arbitrary services. So, we introduced this property to 'name' them - it's a common trick to get something similar to nominal typing.

That trick allows to have type checking all the way down to createInstance.

class A { 
constructor(a:number, @IService service: IService) {

}
}

service.createInstance(A, true) // <- compile error here