Typescript Definitions?

[awwong1]

Is there any interest in adding typescript definition files to this project? I currently have a working definitions file that I submitted to DefinitelyTyped but perhaps it would be better to make it more generic move it here instead. https://github.com/DefinitelyTyped/DefinitelyTyped/pull/31284

[mattwelke]

I'm familiar with TypeScript and I could help maintain type definitions in this repo if the owner agrees to have type definitions live here.

[dougmoscrop]

I don't use TypeScript but I certainly want to support what people need

[mattwelke]

@dougmoscrop Generally, when people want to add type definitions to a library, they take one of three approaches:

1. Convert the JavaScript code to TypeScript. When it's compiled, type definition files will be produced automatically which are guaranteed to line up to the source code. The DefinitelyTyped project (@types packages) deprecates their community-contributed package if one exists and recommends you use just the main package itself.
2. Keep the JavaScript code as is, but manually create .d.ts files in the repo as well. It's up to the .d.ts file creators to get the types as accurate as possible. Just as with the DefinitelyTyped project, it's possible for mistakes to be made or for types to get out of sync.
3. Do nothing and allow the DefinitelyTyped contributors to create a @types package for us. Same possible problems as option 2 and TypeScript devs have to install the main package and the @types package to use the types, but this is perfectly acceptable if the project maintainer chooses not to embrace TypeScript, which is their prerogative.

I can help with options 1 or 2 because of my interest in this project. Just to put it out there, I'm also interested in investigating if the same techniques used to support AWS Lambda can be used to support Google Cloud Functions, and working on adding support for Cloud Functions to the project.

[dougmoscrop]

Sounds great, I think 2 is fine given the size of this project; I don't intend on changing the interface very much.

I have some code where I started to already refactor the main .js file to support multiple providers, I will try to push this soon, I just got back from vacation so I am catching up at work.

[mattwelke]

Sounds good. No rush, I'll mainly have time to submit PRs on weekends. One thing I was going to suggest when I got in touch with you is that it would make sense for it to eventually be a breaking change to support multiple providers, so that instead of this:

const awsAdapter = require('serverless-http');
const gcpAdapter = require('serverless-http').gcp;

You would have this:

const awsAdapter = require('serverless-http').aws;
const gcpAdapter = require('serverless-http').gcp;

And it would treat each provider as a first class citizen. But in the mean time, you could always alias .aws to importing the library itself, to defer that breaking change.

[dougmoscrop]

Yep, although I had been thinking we might want to pass the provider in as an argument, something like:

const serverless = require('serverless-http');

module.exports = serverless(app, {
  provider: process.env.PROVIDER
});

That way if you were using say Serverless, you could set the environment up to the provider name and deploy the same code. I don't personally use multi-provider/etc but it seems harmless as a convention?

[mattwelke]

I think that either API would work to achieve that goal. Mine would simply be rewrote to require('serverless-http')[process.env.PROVIDER]. But I actually like your style better anyways now that I see it, because there may be more parameters you would want in the future to determine what "adapter" object is returned by the serverless function in your snipper. Ex. a parameter for people to specify the middleware framework (Express, Koa, etc) so that it would rely less on this library inferring the middleware framework by examining the app object. If frameworks start to become too similar, it might get hard to infer the middleware framework.

[dougmoscrop]

Multi-provider foundation is in main, and typescript defs too, closing this