Reputation: 13882
I have recently started working with typescript.
I have a typescript project setup which has a lot of React components written with typescript.
These typescript components usually export the component itself and to make development convenient, I have extracted all the types required by this typescript component to a separate file. Now usually you would have to import these types in your component to use it, but since it was cumbersome, some one in the team came up with an idea to name these separate file containing types as types.d.ts
(or whatever.d.ts). This makes the types available globally across the project, without needing to explicitly import the types anywhere.
Now, I understand that type declaration files are only required in case I am consuming a javascript component in my typescript project, and if I want to have type checking working for that javascript component. In which case, I can either get the type declaration file from outside (like, DefinitelyTyped) , or I can create a local declaration file. This is not what i am using a declaration file here for.
But i would like to understand what are the problems with this usage?
NOTE: This separate file which is named as d.ts does not really follow any specific guidelines that may be required for declaration files. This just has some regular interface declarations
Upvotes: 2
Views: 2247
Reputation: 76
TS team is against this practice, TS sees .d.ts files as an associate of .js file only to provide type safety.
This has few problems as well
There will be no type checking for this file if you use skipLibCheck
option in your tsconfig
.d.tS files are for putting things in global scope or alter global scopes in your projects so let's say you write some type in .d.ts it will be available to all the components in your code.
Let's say there are multiple .d.ts files in your code and if there are multiple interfaces with same name they will merge (in case of interface) and may require in un-expected errors.
There is a typescript repo thread as well for this same discussion https://github.com/microsoft/TypeScript/issues/52593
Upvotes: 0
Reputation: 13882
Some observations:
in a .ts
file (or a d.ts
file), if there is no top level export, it would be considered a global script (similar to how this works in javascript) and everything in the script would be available globally. This is how the types are exposed globally in my case (again, it does not have to be a .d.ts
file)
if you a ts
file and a d.ts
file with the same name, the compiler ignores the d.ts
file and that is why it is not possible to expose types for Component.tsx
using Component.d.ts
(you would need to name the d.ts
file something else)
when importing an external module without type information, typescript suggests to add a d.ts
file with declare module moduleName
, instead of this you can also just add a regular .d.ts file with a top level export inside moduleName/index.d.ts
So, to answer my questions:
it might not be wrong to expose all the types globally used within your application, but then you have to take care of any namespacing/naming conflicts. In this case, using d.ts
file is not required, this setup would just work as well with a .ts
file exposing the types globally.
Another way to achieve this would be to export types from respective files and import them wherever required.
in this setup, the only problem with the compiler which may arise is when the .d.ts
file is named same as the .ts
file, in which case the .ts
file would override and types from .d.ts
would not be available globally.
the compiler generates the declaration files from ts
files, and that is mostly required if you need to publish your types. In our case, the types are internal and we won't really need to generate the declarations. Our usage, as discussed, is not dependent on the file being a declaration file, it will work just as well in a .ts
file and we shouldn't be using .d.ts
file for this. So, no, there wouldn't be any impact.
Upvotes: 3