question: Still maintained?

[StarpTech]

The only activity I see is from a bot. There are a lot of unanswered questions. Any status update would be great.

[JipSterk]

i don't want to sound bitter but if it were still maintained shouldn't you have had a reply already?
i just went scrolling through the history of the repository and all the recent activity has been by dependabot.
the last merged commit excluding docs changes is 9/3/2021

[songkeys]

@NoNameProvided @pleerock Hi. Could we have someone take care of this repo? I see some PRs waiting for approvals like #399 which will improve performance a lot but in lack of code reviews. I would love to help if wanted.

[scriptcoded]

@NoNameProvided @pleerock Hi. Could we have someone take care of this repo? I see some PRs waiting for approvals like #399 which will improve performance a lot but in lack of code reviews. I would love to help if wanted.

I'd be happy to help as well

[bradenmitchell]

I am looking at using a DI package and was pretty keen on this but considering no maintainers have responded to this issue I think I'll be going with TSyringe.

[songkeys]

Seems that @NoNameProvided and @pleerock are still active on GitHub. But they just barely take care of this repo anymore.

[ramiel]

My two cents on this. This package is in a way the best dependency injection project in the nodejs ecosystem. On the other hand the lack of maintenance is clear: documentation is far from being readable (I struggle all the times), important PR such as #399 are not merged. Can you please consider hand this over to someone else? In this issue already two people showed their interest to help. Another way is to fork, but it would be better to keep this one of course.

[ramiel]

If any of you already looked for an alternative, do you have any suggestion?

[scriptcoded]

@ramiel I guess you could use the NestJS IoC Container standalone: https://docs.nestjs.com/standalone-applications

[ramiel]

@scriptcoded thanks for the hint but I probably prefer something that does just the IoC job, without getting all the code from NestJS. I don't know how bloated is to get that package just to use its IoC part.

[scriptcoded]

I guess forking could be a valid alternative here?

[jbmikk]

I think this is a very good library. I would like to have this maintained as well. I could even contribute.
If anyone forks please let us know.

[South-Paw]

Some sort of reply would still be nice @NoNameProvided @pleerock

[brooksvb]

I am looking at using a DI package and was pretty keen on this but considering no maintainers have responded to this issue I think I'll be going with TSyringe.

Thanks for the pointer! I tried looking at a few options. https://brandi.js.org/ seems popular and well-supported, but it requires more manual boilerplating :/

typedi is really nice with how straightforward and simple it is. It's a shame that it's not getting any proper attention from maintainers. TSyringe is supported by Microsoft, and seems to be able to get you going with low-config decorator-based service definition and automatic constructor injection. Will be giving it a spin.

[NoNameProvided]

The only activity I see is from a bot. There are a lot of unanswered questions. Any status update would be great.

I had no time to focus on the typestack or any other OSS projects in the last year. However, I would also not call 30 open issues a lot. The majority of those are questions (haven't checked yet) that can be answered by the community.

I don't want to false give hope, so it's important to say even when I will have time I will probably focus on class-transformer and class-validator first.

Some sort of reply would still be nice @NoNameProvided @pleerock

pleerock is not maintaining the typestack projects for a long-time now.

I'd be happy to help as well

For people who offered help, please reach out to me at: [email protected].

I feel it's important however to stress that as a maintainer your task is:

• helping others use the lib
• helping others to figure out how to solve their use case with the current functionality
• confirming and fixing bugs
• writing a functional documentation (because we have none at the moment)

All typestack projects (typedi less so) suffers from feature creep as in the past anyone requested anything it got into the projects. This is not the goal now, so please keep this in mind.

In the past, I had bad experiences with collaborators who just joined and merged their own PR to never be seen again.

Obviously, help is always appreciated and I am happy to onboard anyone but keep these rules in mind pls.

[rcollette]

TSyringe hasn't had a release since 2020 and a similar number of issues awaiting triage.

[freshgum-bubbles]

I guess forking could be a valid alternative here?

Hiya, just an update: I've forked TypeDI.
I've made quite a few substantial changes to the underlying API,
and added a few very nice-to-have features:

• Resolution constraints: Optional, SkipSelf, Self, Many. This is very much copied from Angular: you can use them to change the strategy used for resolving a certain dependency of a service.
• Removal of property injection (which is a real anti-pattern) and parameter injection; removed as it isn't a feature in the official decorator spec; therefore, it's at a strong risk of being removed -- see Deprecate @Host(), @Inject(), @Optional(), @Self() & @SkipSelf() angular/angular#50439. It's been removed with a more sensible API that has the exact same functionality.
• Proper container inheritance through of and ofChild (and an API for creating containers with no parent)
• Easier use in JavaScript through the JSService function, without any manual calls to Container.set required.
• ESM bundles (comes in at 7kB for the curious) alongside UMD.
• getOrNull and getManyOrNull methods for resolving identifiers (alongside the former error-throwing APIs)
• No more passing containers into services unexpectedly and causing runtime errors (re: Question: Why my custom decorator injects the ContainerInstance? #571); although... the used container isn't currently attainable anywhere else, I'm definitely looking into that as it is one of my use-cases.
• Investigating disabling eager services by default (see Disable eager services by default in ContainerInstance freshgum-bubbles/typedi#17); though they can easily be re-enabled through a method call -- they come with a lot of drawbacks IMO, and can cause some real confusion if you're not careful with them.
• An experimental tree visitor API (see Visitor (ContainerTreeVisitor) API freshgum-bubbles/typedi#14) which allows you to traverse containers, child containers, and their respective services from a single object.
• Cleaning up some dead code in the project.
• Some proper documentation on the way; I always felt really let down by TypeDI's docs.
• An actively maintained project 😉

It's still a WIP, though!

Grr...

TBH I got really sidetracked here; I liked the concept of TypeDI but disagreed with some parts of its implementation, which led into me creating a fork of that that I'm eventually going to use in the project I was originally working on.

Documentation is being worked on right now: freshgum-bubbles/typedi#19.
I will be maintaining the library actively; as a heavy user of DI in TypeScript, I need a container that works.
I'd be happy to accommodate any (reasonable) feature requests too, assuming they fit well into the project and don't result in death by a thousand features (and ways to do one thing).