You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#158 essentially proposes a compatibility layer which allows the usage of ++ in places where typestack's implementation is expected.
I definitely think this is worth exploring; it's not a use-case I originally considered,
but I do think it would expand the horizons of where ++ could be used.
A wise investment would be creating a list of incompatibilities with source.
Let's do that here.
xxx
General compatibility with typestack
Compatibility with typestack has been a bit of a bug bear of mine.
I've been meaning to make it easier to migrate to this one.
I can only imagine the work required to have to migrate at-once; this could definitely be made easier.
The text was updated successfully, but these errors were encountered:
would this mean addressing the doubled references? #152 - then we could swap the dependency and we're done. Right now it would be a huge effort for us to go through every file and double up the references everywhere
would this mean addressing the doubled references? #152 - then we could swap the dependency and we're done. Right now it would be a huge effort for us to go through every file and double up the references everywhere
Yes, that would be supported. I'm aiming for 1:1 compatibility with typestack's implementation, where it's just a matter of swapping the typedi import with @freshgum/typedi/contrib/....
The ContainerInstance implementation is partially completed, alongside that of ContainerRegistry.
Note that I'm still working on this suite: it's going to be a moderately large effort, as I'd like to get my implementation to pass typestack's test suite (which means importing https://github.com/typestack/typedi as a submodule and applying a .patch for the test files' imports.)
Compatibility layer with
typestack/typedi
#158 essentially proposes a compatibility layer which allows the usage of ++ in places where typestack's implementation is expected.
I definitely think this is worth exploring; it's not a use-case I originally considered,
but I do think it would expand the horizons of where ++ could be used.
A wise investment would be creating a list of incompatibilities with source.
Let's do that here.
General compatibility with typestack
Compatibility with typestack has been a bit of a bug bear of mine.
I've been meaning to make it easier to migrate to this one.
I can only imagine the work required to have to migrate at-once; this could definitely be made easier.
The text was updated successfully, but these errors were encountered: