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

TypeScript Support [Help Wanted] #589

Open
willfarrell opened this issue Dec 30, 2020 · 8 comments
Open

TypeScript Support [Help Wanted] #589

willfarrell opened this issue Dec 30, 2020 · 8 comments

Comments

@willfarrell
Copy link
Member

@willfarrell willfarrell commented Dec 30, 2020

TypeScript support is made up 100% from community contributions. None of the core maintainers know or use TypeScript and thus are unable to offer support for it. We believe that TypeScript has value to some and are willing to merge in changes the community find valuable.

If you would like to make Middy better, please consider submitting, reviewing, and/or commenting on PRs/issues. We generally like to give a week before merging a PR to give the community time to comment.

TypeScript Issues

@lmammino
Copy link
Member

@lmammino lmammino commented Jan 3, 2021

Any reason for moving type definitions outside every project and into @types/x ?

I personally prefer to keep them colocated just to make it easier to update them every time something changes.

Am I missing something important here?

@willfarrell
Copy link
Member Author

@willfarrell willfarrell commented Jan 3, 2021

It was more of a question on what is TS best practice. See #591
Definitions are not going anywhere.

@willfarrell willfarrell removed the v2.x label Jan 17, 2021
@willfarrell willfarrell changed the title Update TS in middy v2 [Help Wanted] TypeScript Support [Help Wanted] Jan 17, 2021
@willfarrell willfarrell removed this from the v2.0.0 milestone Jan 17, 2021
@dbartholomae
Copy link
Contributor

@dbartholomae dbartholomae commented Jan 29, 2021

Best practice would be to have the type annotations right next to the code. If they are a separate file anyway, then maintaining them inside the repo in my experience works a bit better, as long as there are people who actively keep them updated and whose PRs are merged on time.
Concerning types in general, unfortunately, the setup with .use makes it hard to give really good type safety. When we last discussed improved types for this repo, I experimented around it a bit which lead to lambda-middleware. I'm still happy to help here as well, though this structural problem will limit what we can achieve.

@willfarrell
Copy link
Member Author

@willfarrell willfarrell commented Jan 29, 2021

Thanks for commenting and bring attention to that last discussion. I've read a couple times today, will likely need another read. I'm wondering how others like express and other that also use the .use pattern have solved this TypeScript incompatibility. Would allowing middy(handler, middlewares) be all that is needed to allow better typing?

Happy to accept any help you can spare. I've updated the list at the top highlight deficiencies in v2. Just open a PR, I'm pretty active these days.

@dbartholomae
Copy link
Contributor

@dbartholomae dbartholomae commented Jan 30, 2021

I'll take a look. I fear that there might be further complications, though, as TypeScript will need to know the order in which middlewares are applied, and this order only partially depends on the order in which the middleware is added.

@willfarrell
Copy link
Member Author

@willfarrell willfarrell commented Jan 30, 2021

There are some lesser known hooks in core that might help.

  1. .use([...]) can take an array of middlewares
  2. middy(handler).__middlewares returns the arrays of the before, after, onError in their execution orders.

@KillDozerX2
Copy link
Contributor

@KillDozerX2 KillDozerX2 commented Jul 22, 2021

Not to fuss much, but we are initially in the process of migrating to TS and we use typescript compiler to generate types from JS Doc and it seems to be working for some of our internal packages, maybe the core maintainers could give that a look, until someone from the community takes charge of it.

@willfarrell
Copy link
Member Author

@willfarrell willfarrell commented Jul 25, 2021

@KillDozerX2 I tried to do that for v2, but was missing the ability to load in external custom definitions (if I remember correctly). In the end we ended up with what we have now, I far as I know it's serving peoples needs for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants