Skip to main content

Announcing 7.0.0-alpha.0

· 2 min read
Roberto Pintos López
Roberto Pintos López
InversifyJS maintainer

It's been a while since the last time inversify released a major version. Some exciting changes are on their way, and we are announcing them in a prerelease so you can participate and discuss them before it's finally released.

Feel free to check out the next version docs.

Notable changes​

Injection inheritance​

Previous versions of inversify provided implicit injection inheritance. However, this approach was deprecated in favor of the @injectFromBase decorator. This decorator allows you to inject dependencies from the base class.

Refer to the inheritance docs for more information.

Factory-like bindings​

Factory, Provider, and DynamicValue bindings now receive a ResolutionContext. Refer to the API docs for more information.

Motivation​

Previous Context and Request exposed objects provided internal data which should never be accessed by users. ResolutionContext allows resolving services in the same way Context.container previously allowed.

Binding constraints​

Some methods have been renamed. No context is passed to the constraint in favor of a BindingConstraints parameter.

Motivation​

Previous Context and Request exposed objects provided internal data which should never be accessed by users. In this specific case, binding constraints are invoked in the planning phase. No resolution-related APIs should be exposed whatsoever, just the metadata used to compute binding constraints such as names, tags, and service IDs in the planning nodes.

Binding activations​

Binding activations now receive a ResolutionContext. Refer to the API docs for more information.

Motivation​

Previous Context and Request exposed objects provided internal data which should never be accessed by users. ResolutionContext allows resolving services in the same way Context.container previously allowed.

Incoming changes​

Some additional changes will be shipped in the inversify@7 release.

Performance optimizations​

With these binding constraint models, it's now reasonable to assume a service plan is cacheable. Planning caches should dramatically improve container performance when providing services.