Sendgrid-nodejs: Package depends on @types packages at runtime

[garybernhardt]

Issue Summary

TypeScript packages like @types/request are intended as development dependencies. @types/request contains no executable code; only a non-executable index.d.ts file. However, the @sendgrid/client package depends on @types/request, which brings in another five type packages, including @types/node.

Unless I'm missing something very unusual that makes them necessary, these dependencies don't serve any purpose. However, they do slow down deploys and bloat up users' node_modules directories.

Steps to Reproduce

1. npm install @sendgrid/client.
2. npm ls
3. Several "@types" packages are listed.

Suggested Solution

Move "@types/request" from the "dependencies" key of package.json to the "devDependencies" key. (I've been using this package for less than an hour, so I wanted to open this issue out of caution rather than submitting a PR.)

Technical details:

• sendgrid-nodejs Version: master (latest commit: f94a3924db7fd1380a341af1903955f5c526d0ba)
• Node.js Version: 11.7.0
• NPM Version: 6.5.0

[thinkingserious]

Thanks for the feedback @garybernhardt!

@SPARTAN563 @adamreisnz

Do you have any thoughts on this?

For now, I'm adding this to our backlog for further review. Thanks!

[adamreisnz]

Are those packages for TypeScript users?
If so, best for @SPARTAN563 to comment on this, they can probably go to devDependencies.

[notheotherben]

Thanks for opening this ticket, that's a very good point and I'll quickly put together a PR to fix it.

[thinkingserious]

Why do you all have to be so awesome?

[matheo]

Too awesome to be true,
a simple PR not merged nor released in a month and a half :-?
@SPARTAN563 @thinkingserious

[notheotherben]

Sorry @matheo, not much I can do to help on that side of the process, just a community contributor here doing my best to help.

[adamreisnz]

The bottle next appears to be the review and merge process of PR's, and subsequent new releases. Perhaps part of this work can also be handed over to some community contributors, to speed things up.

I agree that it is demotivating if a problem is identified, and a PR to fix it is prepared in a few days, but then it takes months until it's reviewed/merged/released.

@thinkingserious thoughts? Feasible within the constraints of Sendgrid's legal requirements?

[thinkingserious]

Thank you for being so responsive @SPARTAN563 & @adamreisnz!

Indeed, sadly we are the bottle neck here.

We are now in the process of designing systems and obtaining the resources needed to fix this issue. One of the avenues we are exploring is empowering our community to help move these PRs forward. Last time we considered this, legal concerns were the show stopper. This may no longer be true, however. I will be in touch with regards to the final outcome of our renewed exploration.

To @garybernhardt & @matheo & our valued community,

I am deeply unsatisfied with our current state and am working towards change. I do appreciate your patience during this transition and I'm looking forward to a much improved experience.

With Best Regards,

Elmer

[garybernhardt]

No problem. Glad to hear that you're working on a quicker process. As a long-time customer, I'd definitely prefer that, at minimum, nothing ever gets merged without full review from a SendGrid developer. SendGrid has mostly been stable for me and I'd hate to trade any stability away to get a PR merged a few days earlier.

Thanks for merging!