Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal : Augment resources typing #58

Closed
wants to merge 4 commits into from

Conversation

ymoriaud
Copy link

Hello ! 👋

I'm just discovering this library (thanks for the awesome work !) and I was struggling with callback typing. I saw the issue #45 and I wanted to share a potential solution.

Disclaimer : this PR is draft, the test is only done for the SCIMMY.Resources.User.ingress function.

Since the SCIMMY.Resources.User extends SCIMMY.Types.Resource and bring some override, I notice that typescript handle it better if we define a specific callback type for IngressHandler.

I also changed the return type of SCIMMY.Resources.declare by adding a dynamic type based on the declared type.

Here is an example that you can use in VSCode to test augmented typing.

SCIMMY.Resources.declare(SCIMMY.Resources.User)
    .ingress((resource, data) => {
        /* Handler for creating or modifying user resources */
        console.log('Creating resource:', resource)
        console.log('Data', data)

        const user = {}
        return user
    })

Here is an example on how VSCode display the type for ingress.
image

@sleelin
Copy link
Collaborator

sleelin commented Dec 6, 2024

Hi @ymoriaud, apologies for the delay in addressing this PR!
Thanks for your contribution! It doesn't quite address the underlying issue and isn't a full solution (the other resource types have the same problem), so I can't merge this as-is.

The underlying issue is that the type definitions generated from the JSDoc annotations by the TypeScript compiler are functionally useless - when they don't just fall back to the "any" type, they often just outright get the type wrong.
I've been working on a new tool to manually generate the types, and have had much better results, including using the @template tag as you suggested to generate generic types.

I'm closing this for now as I have a more comprehensive solution on the way shortly!

@sleelin sleelin closed this Dec 6, 2024
@ymoriaud
Copy link
Author

ymoriaud commented Dec 6, 2024

Hello @sleelin ! Thanks for your answer. Congrats for the new tool !
Feel free to ping me if you are looking for some help or testers.

Have a great day.

@sleelin
Copy link
Collaborator

sleelin commented Dec 8, 2024

Thanks @ymoriaud! I've just released v1.3.0 which should include a type definition file generated with the new tool, would you mind updating to this version and reporting back firstly on whether it actually produced functioning types, and secondly to see if it raises any other typing issues?

Thanks,
Sam

@ymoriaud
Copy link
Author

ymoriaud commented Dec 9, 2024

Thanks @sleelin and congrats for the release ! I'm answering in the #45 to centralize everything. If you prefer for me to create a new issue, let me know. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants