Steps to Reproduce
- Create an injectable using either
createInjectable or createInjectable.root
- Declare optional parameters with default values, such as:
const [injectFn, provideFn] = createInjectable('BaseUrl', (baseUrl = 'https://...') => baseUrl);
Expected Behavior
- The return type of
injectFn should be inferred based on the default value's type: in the example above, it should be typed as string
- The expected argument type for
provideFn should be inferred based on the default value's type: it should accept baseUrl?: string
Actual Behavior
- The return type of
injectFn is any
provideFn expects baseUrl?: any
Signality version
0.3.0
Angular version
=20
Browser
None
Operating system
None
Additional Context
To completely resolve this type inference issue, I decided to stop enforcing optional arguments for createInjectable.root.
While enforcing this would have been safer at compile time (to prevent errors if the resulting injectable is never explicitly provided with arguments), it made fixing the type inference highly complex. The workaround required returning never instead of CreateInjectableRef if at least one parameter was required.
Although this approach worked, the typing lost its consistency with createInjectable and became quite difficult to read. Therefore, I chose to drop this strict constraint and instead rely on developers to be mindful of this specific case when using the utility.
I will add a warning about this behavior in the documentation.
Steps to Reproduce
createInjectableorcreateInjectable.rootconst [injectFn, provideFn] = createInjectable('BaseUrl', (baseUrl = 'https://...') => baseUrl);Expected Behavior
injectFnshould be inferred based on the default value's type: in the example above, it should be typed asstringprovideFnshould be inferred based on the default value's type: it should acceptbaseUrl?: stringActual Behavior
injectFnisanyprovideFnexpectsbaseUrl?: anySignality version
0.3.0
Angular version
Browser
None
Operating system
None
Additional Context
To completely resolve this type inference issue, I decided to stop enforcing optional arguments for
createInjectable.root.While enforcing this would have been safer at compile time (to prevent errors if the resulting injectable is never explicitly provided with arguments), it made fixing the type inference highly complex. The workaround required returning
neverinstead ofCreateInjectableRefif at least one parameter was required.Although this approach worked, the typing lost its consistency with
createInjectableand became quite difficult to read. Therefore, I chose to drop this strict constraint and instead rely on developers to be mindful of this specific case when using the utility.I will add a warning about this behavior in the documentation.