2

At work we have a large project that was originally created with namespaces on typescript 1.x, after being migrated from a mix of global scripts, and Immediately Executed functions assigned to variables to mimic classes, in JavaScript.

It's currently on typescript 2.5, and most (but not all) of the interfaces (we write for our classes) are defined in .d.ts files.

In addition, there are quite a few out-of-date .d.ts files for external libraries, that cause errors that have been worked around because we are not using @Typed packages, and the versions of the types don't necessarily match the js library OR the current version of typescript, this is clearly a bad situation.

If I delete all the .d.ts files, I get errors, because understandably it's the only place our interfaces are defined.

I asked someone why it was done this way, and I was told that declaration files in TS for interfaces can act as C headers do, speeding up compilation, type checking, and assist external libraries accessing the code.

Therefore I think the original intention, was to have these files as a form of early module, but now our project has gotten messy using both es6 style import/export statements,

namespace place.UI.group {
    import IDetailsConfiguration = Configuration.IDetailsConfiguration;
    import IGroupConfiguration = Configuration.IGroupConfiguration;
    import LookupValueDataService = Data.LookupValueDataService;

    export class GroupViewModel extends kendo.data.ObservableObject {

and commented out references to old .d.ts files e.g.

/// <reference path="../../../../typings/jquery.d.ts" />

/// <reference path="../../../typings/Config/IBillsConfiguration.d.ts"/>

and I fear that a subtle bug may arise somewhere due to developers not understanding the differences between namespaces and es6 modules (Myself amongst them!).

Should TypeScript Interfaces Be Defined in *.d.ts Files answers the question of interfaces in declaration files nicely, But does separating out the interfaces speed up inference / compilation / analysis? And if so, is there a better method of separating the public interfaces out of theses pseudo-module namesspaces, then manually creating .d.ts files, when the types are already available? Or is the tsc compiler smart enough to do this with the right compiler flags?

Ryan Leach
  • 4,262
  • 5
  • 34
  • 71
  • Can you give a concrete code example, what you are trying to do/improve/refactor? I gave an answer in your mentioned post, maybe that already helps. – ford04 Feb 06 '20 at 10:01
  • My question is about obtaining knowledge about whether defining interfaces in a .d.ts file have an advantage in compilation performance (specifically) or any reason in general. From my point of view, having .d.ts files for other projects cause them to be underspecified, and out of date, compared to using known package management techniques, (which we don't yet use for types) I want to be able to use official 'typings' rather then these out of date versions, however our own ts files have several .d.ts files containing interfaces. They may be remnants of old code, left over frm migrating from js – Ryan Leach Feb 14 '20 at 07:19
  • 1
    I doubt there is any performance advantage of writing the same code in a different place. The purpose of .d.ts files as I understand it is that you can ship a JavaScript library/API and then provide typings for it without having the whole API code duplicated. If there's a performance advantage it's that users don't need to recompile your API from Typescript to JavaScript when building their projects. If you're actually writing and modifying the API code then you do have to recompile it, though. – kaya3 Feb 14 '20 at 08:47

0 Answers0