Ts-node: Move @types deps to devDependencies

[wclr]

There is a bunch of @types packages in dependencies, seems they should not be needed by the end user, just for the sake of keeping things clean.

[stelcheck]

I believe this is incorrect; for instance, you may want to use this repository programmatically to create your own customized TypeScript-enabled REPL. In such case, I believe the types need to be present for your dependent code to compile, but let me know if this is incorrect.

[wclr]

It depends on whether exported API uses those typings or not.

    "@types/arrify": "^1.0.1",
    "@types/diff": "^3.2.1",
    "@types/minimist": "^1.2.0",
    "@types/mkdirp": "^0.5.0",
    "@types/node": "^8.0.27",
    "@types/source-map-support": "^0.4.0",
    "@types/v8flags": "types/npm-v8flags#de224ae1cd5fd7dbb4e7158a6cc7a29e5315930d",
    "@types/yn": "types/npm-yn#ca75f6c82940fae6a06fb41d2d37a6aa9b4ea8e9",

I see that https://github.com/TypeStrong/ts-node/blob/master/src/index.ts#L29 exported interfaces don't use them.

[blakeembrey]

It would be nice to do, for the sake of keeping things clean, but we can't really guarantee or easily test that these interfaces won't be accidentally exported at some time in the future. For that reason, I'd prefer to keep the @types in the same location as the plain dependency.

[wclr]

For that reason, I'd prefer to keep the @types in the same location as the plain dependency.

Well, my point is this need to be checked and the author should understand what they exposing or what not, ts-node API surface is not so huge to be really difficult to reason about for sure.

[stelcheck]

@whitecolor A human error remains quite possible. Do you know of a TypeScript tool that allows verifying that the exposed types need to be shared or not?

[wclr]

Do you know of a TypeScript tool that allows verifying that the exposed types need to be shared or not?

Some checks are done while tsc produces declarations. Also, this test TS API could be done in CI (with removed dev deps), but I'm not sure that it does worth the efforts.

[blakeembrey]

To resolve the issue with the proxy, we could get the types into @types instead of using GitHub URLs too. As for figuring out dev and not dev, I could build a tool for it - it could be a modification/plugin of something like https://github.com/maxogden/dependency-check. I'll reopen with the intention that we do that before moving the dependencies.

[wclr]

Not sure how https://github.com/maxogden/dependency-check may help with @types deps.

[blakeembrey]

@whitecolor You need to recursively traverse type definitions and alert when any dependencies are either extraneous or missing. Seems like a similar tool to what it does today, just need a different entry point and a parser for .d.ts files.

[cspotcode]

Closing because I think this is effectively solved. The only types referenced in our declarations are make-error, and it bundles its own declarations, so it's not @types. Since more and more libraries are bundling their own declarations, this is less and less likely to be an issue.