added declarations for react-router-navigation packages

[kaoDev]

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If adding a new definition:

• The package does not provide its own types, and you can not add them.
• If this is for an NPM package, match the name. If not, do not conflict with the name of an NPM package.
• Create it with dts-gen --dt, not by basing it on an existing project.
• tslint.json should be present, and tsconfig.json should have noImplicitAny, noImplicitThis, strictNullChecks, and strictFunctionTypes set to true.

this PR contains declarations for 2 packages from https://github.com/LeoLeBras/react-router-navigation

the lib owner has suggested to put the declarations into the DefinitelyTyped Repo winoteam/react-router-navigation#36

[typescript-bot]

@kaoDev Thank you for submitting this PR!

Because this is a new definition, a DefinitelyTyped maintainer will be reviewing this PR in the next few days once the Travis CI build passes.

In the meantime, if the build fails or a merge conflict occurs, I'll let you know. Have a nice day!

[typescript-bot]

@kaoDev One or more reviewers has requested changes. Please address their comments. I'll be back once they sign off or you've pushed new commits. Thank you!

[ghost]

Remove this line -- we use tslint and not eslint

[kaoDev]

oh yes of course, this line slipped in from the original code

[ghost]

Could you try to narrow this test down to just using these two things? This seems to mostly be testing other react packages.

[kaoDev]

yes I will do, for this test I just copied one of the Lib files which use the core-lib

[ghost]

A test file shouldn't have exports.

[ghost]

It would be better to just use the default tslint rules instead of adding exceptions for some packages.

[kaoDev]

this also has to do with my preference of types over interfaces, but if there are good arguments for the different rules I can get convinced 😄

[ghost]

Intersecting two types never fails, while interfaces bring more guarantees.
Also, when you use an interface we are able to use the type name in more places.

type T = { a: number; x: number };
type U = T & { b: number; x: string };
declare const u: U;
u.a; // (property) a: number
u.b; // (property) b: number
u.x; // (property) x: number & string

interface I { a: number; x: number; }
interface J extends I { b: number; x: string; } // Error, bad override of 'x'
declare const j: J;
j.a; // (property) I.a: number
j.b; // (property) J.b: number
j.x; // (property) J.x: string

[kaoDev]

okay I see the benefit with the bad override, thank you for the explanation. But still don't know if I'm completely convinced, because interfaces allow declaration merging what I think is quite dirty, because it spreads the definition to different places.
Also the behavior of intersection types is very close to the behavior of object merging in JS, so I think of it as the typed equivalent of Object.assign

type T3 = T1 & T2
const a: T1
const b: T2
const c: T3 = Object.assign(a, b)

But all arguments aside in this specific case I still want to stay with types instead of interfaces just to stay closer to the original code in flowType.
https://github.com/LeoLeBras/react-router-navigation/blob/master/packages/react-router-navigation/src/TypeDefinitions.js

[ghost]

Unless the value is actually number & string at runtime, it's not more accurate to the runtime behavior! The compiler and language service work best on named over anonymous types -- please stick to the DefinitelyTyped lint rules.

[kaoDev]

hmm you are making it more difficult than it should be to contribute type declarations.
As I already said the main reason to use types instead of interfaces is that the original code written in FlowType also uses types instead of interfaces.

If I would use interfaces everytime the original code changes there will be the transfer from type to interface again. By using types it is almost just copy and paste.

[kaoDev]

another argument to stay with types for this lib is, that the implementation of intersection types in flow is the same as in typescript, with the same pitfalls (https://flow.org/en/docs/types/intersections/#toc-intersections-of-object-types)

So with interfaces instead of types there would be a real difference to the original typings

[ghost]

Why use any and not the intersection?

[kaoDev]

because it is taken directly from the flow-types of the package. I hope those types will get finalized when the lib gets beyond RC state

[ghost]

It's better to use interface inheritance instead of intersection types.

[kaoDev]

what are the exact benefits of interfaces vs types? I personally prefer the type keyword because it is close to other functional languages.

[typescript-bot]

🔔 @andy-ms - Thanks for your review of this PR! Can you please look at the new code and update your review status if appropriate?

[ghost]

Merged with manual lint fix. In future please update code to conform to DefinitelyTyped standards instead of just pasting code from other programming languages.

[kaoDev]

for me the main target for declarations is to be consistent with the described code, so in this case it's not about being able to copy the original code written in FlowType but to be consistent.
The tslint rules were not capable of representing the declarations representing the original code, so it is just natural to have a customization there.