It's nice to explicitly state types at module boundaries, which will make it easier for other developers, theoretically allows some type-checking optimizations, and will prevent you from accidentally changing your API.
I've been starting to build speed-focused TS type-checker that is intended to be used in single-file editors like VIM to highlight errors, because it starts checking from a single file and just traverses files necessary to check types within that one file. If you defined your types at a module boundary it can bail out super early, since it doesn't need to look at the rest of the code of that module at all.
Most linters have rules that will force you to explicitly declare types at module boundaries.
Very cool. I'd recommend reading the built-in vscode extension for TypeScript, because with 4.0 we added a feature very close to that for editors into TypeScript and you can rely on our work instead. Links in: https://www.typescriptlang.org/docs/handbook/release-notes/t...
I've been starting to build speed-focused TS type-checker that is intended to be used in single-file editors like VIM to highlight errors, because it starts checking from a single file and just traverses files necessary to check types within that one file. If you defined your types at a module boundary it can bail out super early, since it doesn't need to look at the rest of the code of that module at all.
Most linters have rules that will force you to explicitly declare types at module boundaries.
Other than that, do whatever you prefer.