Added typescript definition files

[ilikejames]

Hand rolled types, though many are copied from the base type definition within express-serve-static-core.

A few things to point out:

1. using Router without new will cause a type error.
2. Request interface used in express is specific to express. I could have used node's http.IncomingMessage type, but I felt having this be isomorphic would be better as this is how I'd be using this. I think the code could be changed (non-breaking) to support different run-time environments better using generics but thats something i'll have to think about. In the meantime, this parameter should be cast.
3. Response as above.

I've added a test for the typechecking. Hopefully this will catch any deviations going forward.

Ref #48

[ilikejames]

Looks like typescript (for the test) requires "node": ">=4.2.0", though it seems to be building for versions >=0.12. I've removed the bottom two versions. I know this isn't great but 0.10.0 did get released 6 years ago.

Edit: I've rolled back to typescript@1.8.0 and back to targeting master. This should work still with older node versions. As it just used for the tests it should be any impact.
Edit: I've targeted 2.0. Using older version of typescript will be a nightmare to fix the configure issues. So many breaking changes back then.

[dougwilson]

Just a couple initial nits, but otherwise, awesome! And thanks for even adding a test for validating the typings!

[dougwilson]

Please add these back; this version of the module supports these Node.js versions. Removing support is a major version bump. You can retarget your PR to the 2.0 branch if you want to make a breaking change, though.

[ilikejames]

I'll retarget as typescript won't work with such old versions of node. I'll first try seeing if there is allow_failures that can be used for this specific test.

I'll also thinking that this maybe better pushed to @DefinitelyTyped. This way there would be locked @typings/router@1.3.3 version aligned with a publish router@1.3.3 and leave it to the community to update. I often use older package versions simply due to the @type support.

Looking down the list of PRs for 2.0 I not sure what methods we could do to keep these aligned, except by being rigorous for any forthcoming changes.

Up to you guys really. Let me know.

[dougwilson]

There seems to be a lot more methods missing here. Can you add the rest? Examples are .bind, .propfind, etc.

[ilikejames]

.bind and all the default object level props you get for free. I can't find .propfind in the codebase. Not on 2.0 either?

[dougwilson]

All these methods are not in the code base -- they are dynamic depending on the Node.js version -- even the ones like .options is not in the code base at all...

We iterate over https://nodejs.org/dist/latest-v10.x/docs/api/http.html#http_http_methods and add the lower case as a method to the router prototype. Here is propfind existing:

$ node -pe 'require("router")().propfind'
[Function]

[ilikejames]

Ah. So, on my node version i have:

[
     'ACL',
     'BIND',
     'CHECKOUT',
     'CONNECT',
     'COPY',
     'DELETE',
     'GET',
     'HEAD',
     'LINK',
     'LOCK',
     'M-SEARCH',
     'MERGE',
     'MKACTIVITY',
     'MKCALENDAR',
     'MKCOL',
     'MOVE',
     'NOTIFY',
     'OPTIONS',
     'PATCH',
     'POST',
     'PROPFIND',
     'PROPPATCH',
     'PURGE',
     'PUT',
     'REBIND',
     'REPORT',
     'SEARCH',
     'SUBSCRIBE',
     'TRACE',
     'UNBIND',
     'UNLINK',
     'UNLOCK',
     'UNSUBSCRIBE' 
],

So all these should be present I guess.

First thoughts are that this would be correct, but quite noisy, burying more useful day-to-day commands. I've took the original list from the express definitions.
They would be accessible still via array notation route['subscribe']().

I'm guessing this would also be different per node version?
I'm going to be using this library both via node and within browser and this list is bigger than the browser support list.

Its not going to be possible to a run-time version, so I'm wondering what the best direction is now. Full list, partial list of most common, or just documenting that the full set of HttpMethods are available?

Edit: So I see the require('methods'). Obviously this makes this unsuitable for me to use isomorphically from within a web browser, which is annoying. But, as for this PR what do you suggest? As this list of methods is created at runtime it won't be possible to do that same for the types.

My thought it should be a documentation "feature", with the major 99.99% of use cases covered via type definitions, with the documentation saying the full list of methods are available depending on node version via router['method']();.

I'm unsure. What do others think?

[wesleytodd]

So I see the require('methods'). Obviously this makes this unsuitable for me to use isomorphically from within a web browser

Not true. This package is the foundation of the routing I do with nighthawk and works perfectly fine on the browser side. I believe all of the bundlers have browser pollyfills for the methods, but even if not the methods package has a basic list it uses.

[wesleytodd]

For example, this is the shim that browserify uses: https://github.com/jhiesey/stream-http/blob/master/index.js#L58-L85

My thought it should be a documentation "feature", with the major 99.99% of use cases covered via type definitions

I think this is a fine approach as long as the popular tooling can handle undocumented usage well.

[arunesh90]

Noticed a typo
IncommingRequest -> IncomingRequest