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

Feature Request: Include TypeScript Types #34

Closed
theaccordance opened this issue Jun 15, 2020 · 1 comment
Closed

Feature Request: Include TypeScript Types #34

theaccordance opened this issue Jun 15, 2020 · 1 comment

Comments

@theaccordance
Copy link

Hello!

Fellow OSS contributor here, I came across your dependency while adding logging to my micro-service, I really like the scope & design that you've implemented. I can definitely see myself scaling this out to my other services if it works well with this first one!

One non-blocking item I wanted to start a conversation around was adding TypeScript Support. I'm a big TypeScript developer at this point and I do prefer packages with Type Definitions, as they provide both documentation & guards to quality-check the code that's written by myself and my team.

As far what acceptance criteria would look like for this feature request:

  • Adding a types definition file to the published package
  • Adding a types entry to your package.json manifest

I will say from personal experience, writing type definitions by hand is a pain (at least, trying to write them to cover someone else's code), but some packages are inherently more complex than others. I typically resort to converting code to TypeScript and letting the compiler autogenerate the definition file, but I do understand that's a personal preference you may not share. There may also be some tooling that can generate the definition file from the JS code itself.

An alternative way to include types is to publish a separate @types/express-request-logger package, which TypeScript devs download in addition to your package, but IMO that option is best suited for adding type support to unmaintained packages; relying on it for maintained packages just adds extra steps for both the publisher & the dev downloading the dependency.

Let me know your thoughts when you get the chance, like I said this more of a conversation starter than it is an attempt to dictate work. Depending on the outcome of the conversation, I may be open to contributing more to the final solution.

giphy

@ugolas
Copy link
Collaborator

ugolas commented Jun 18, 2020

Hi @theaccordance ,

First of all, glad you likes the package! We use it in our 100+ micro services and its serving us well 💪

Totally agree with your suggestion and points. We also believe the right approach is to convert the entire package to TS.

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

No branches or pull requests

2 participants