Hum OK. I see.

That would introduce different behaviors for resolveAll()depending on whether the token is a string / symbol or a class and this may not be desirable.
And also a different behavior between resolve() and resolveAll() in case of unregistered token.

Is there a workaround for my use case ?

Here is the PR if you're interested: #64

I spoke briefly with @MeltingMosaic and we agreed that the default behaviour for non-registered resolutions should be to fail.

However, I can see a case where we would want to expose opt-in functionality to not fail if, and only if the target is an array or a nullable type. My best guess of how to opt-in would be a flag in the resolution options.

How does that sound?

Hi @Xapphire13,
Thanks for the answer.

If I understand correctly, you suggest something like this:
@injectAll({ resolveWithEmptyArrayOnNothingRegistered: true}) ...
Or a more global setting on the container ?

I think the Angular project solves this issue (cf APP_INITIALIZER, HTTP_INTERCEPTOR, etc.) with an additional @Optional() decorator or similar. That could be a way to do it too.

I’d be OK with both solutions.

@paztek,

I was originally thinking of the first example (maybe with a name like optional or some variation). But I really like the decorator idea!

Do you have time to code up a PR?

@Xapphire13 I can try.
Just to be sure, should I try submitting a PR for:

1. A @inject({ optional: true }) / @injectAll({ optional: true }) option
2. A @optional() decorator ?

Intuitively, 1. seems easier to me.

@paztek, could you give option 2 a stab? I assume the decorator would be on the parameters being injected right?

I like the idea of an @optional() decorator. My concern with it is that it can create some odd behaviors where a service can have behavior that is different in the presence of another registration in the container. If however, the @optional() decorator is limited to array types (for injectAll), I think it's sensible. I know this deviates from Angular's implementation though.

I think it would be safe to allow @optional to work with optional params also. However, we can scope the initial implementation just to array types and improve upon it in the future.

I think it would be safe to allow @optional to work with optional params also. However, we can scope the initial implementation just to array types and improve upon it in the future.

Maybe @optional can provide a default value, like this @optional({ defaultValue: [] })

Have there been any updates on this issue? The @optional({ defaultValue: whatever }) could be very helpful for a project I'm working on. I see there's a PR for what was discussed with arrays but not for this other more general enhancement.

Edit: I created my own PR which tries to implement this if it's any use to anyone.

Totally agree with @SirBernardPhilip

I ran into the same issue, @SirBernardPhilip's solution would be optimal for my use case. Any plans on merging it?