Supports passing a default provider in the inject decorator.

[etiennenoel]

This PR adds the ability to support defining a default provider, directly inside the @inject decorator. Passing both a defaultProvider and isOptional:true, will simply use the defaultProvider, making isOptional: true useless in this case. We could add a warning or error but I think that doing the right thing, which is to use the default Provider is the right call.

Maybe the best thing we should do is use a conditional type like this, so devs can know that it's one or the other.

type InjectOptionsType = {} & (
  | {isOptional?: boolean}
  | {defaultProvider?: Provider<any>});

I think however we would need to increase the version of TypeScript to support this, which I can do in a future version.

This will resolve: #163

[Copilot]

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[Copilot]

Consider refactoring this section to remove the reliance on @ts-expect-error by either upgrading TypeScript or adjusting the overload definitions to properly type-check the defaultProvider.

[Xapphire13]

This looks like defaultProvider has the side-effect of making a registration for the token. I'm not sure how I feel about this.

Seems we could get into undefined behavior territory depending on the order things resolve if multiple things use default providers for the same token.

[etiennenoel]

That's very true. We almost want something like, on resolve, if there is no registration, then check to see if we have a provider in a list of default providers, that we can check into before throwing an error.

[Xapphire13]

Right, so this may need to go into the token descriptor, similar to isOptional.

Though I wonder if we could get it working with ES6's default parameters syntax, since I feel most usages of this would be for default values as opposed to factories and the like.

(if we're registering a factory, we may as well have a full fledged registration; though I could be wrong and not seeing the right use case yet)

[etiennenoel]

For Factories, I could see wanting easily access to the container at runtime. Let me try to put this in the token descriptor to see if that makes more sense.