Service Dependency Type-Checking #38

This utility type allows us to easily type classes with both an expected instance type, and a set list of arguments.

While this implementation is very... verbose, it does work and I see no practical way around it in the current version of TypeScript. I've tried to condense the documentation by way of TSDoc inheritDoc tags, but they don't actually display in solutions such as VSCode. This makes the documentation worse, as the docs for each static overload wouldn't be visible without scrolling to the generic fall-through overload. Currently, the "everything is an option object" overload isn't type-checked. This makes the code a bit less verbose, but it may be desirable.

Add support for using built-ins as dependencies in the type-checking algorithm.

Ensure built-ins are converted to the correct type when type-checking dependencies. For instance, String should convert to string.

The code was never meant to make it into a commit, but oh well.

The new name is more descriptive of what the type does.

Furthermore, simplify the type-resolution algorithm and remove its dependency on arrays with a fixed number of items. The new implementation is compatible with arrays of any size. A major advantage of this implementation is that it **dramatically** simplifies the implementation of dependency type-checking, while also removing the need for multiple Service / JSService overloads. Overall, this means much less code duplication.

This brings the JSService in-line with that of Service.

This makes it more clear what the file does.

This is temporary. I'd like to find a better way. However, currently TypeScript thinks the type is excessively deep if we cast it.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Service Dependency Type-Checking #38

Service Dependency Type-Checking #38

Commits on Jul 18, 2023