microsoft/TypeScript

Guidance on writing declaration file for multi-targeted libraries

jbrantly opened this issue · 7 comments

jbrantly commented

It is now possible for a library to hit every type of target that TypeScript supports (module, namespace, and ES6). Currently, writing a declaration file for a library like this can be very challenging. The default today is something like this:

declare namespace MyLib {
   export ...
}

declare module 'mylib' {
  export = MyLib;
}

This has a couple issues:

  1. If you're using this in the module sense, using this declaration file will result in TypeScript thinking there is a globally available variable MyLib which is not actually true. This can lead to runtime errors. (see #2018)
  2. If you're using ES6 import syntax TypeScript will consider this module to be in the CommonJS style and will not allow default imports even though the library actually supports them.

In the past, regarding item 1, it's been suggested that we split the declarations into two files (one for modules and one for namespaces). This makes sense. I think it also makes sense to extend that concept for ES6 modules. So if you have a library that targets all three, then you will have three mutually exclusive declaration files. Where things then become problematic is with duplicating the declarations in each file (which ideally should not happen). It is impossible to import an ambient module into an ambient namespace. It is possible to use an ambient namespace in an ambient module, but a naive approach to that (as shown in the common case above) violates item 1.

Therefore, I propose this guidance to writing these declaration files.

// mylib-common.d.ts

declare namespace __MyLib {
  export ...
}

// mylib-namespace.d.ts

/// <reference path="mylib-common.d.ts" />
import MyLib = __MyLib;

// mylib-module.d.ts

/// <reference path="mylib-common.d.ts" />
declare module 'mylib' {
  export = __MyLib;
}

// mylib-es6.d.ts

/// <reference path="mylib-common.d.ts" />
declare module 'mylib' {
  export * from __MyLib; // this doesn't currently work, see #4336
  export default __MyLib; // if there is a default export
}

Unfortunately this is currently hypothetical since you cannot re-export namespace declarations from an ES6 declaration.

I'm proposing this as a baseline for discussion to solve this issue for good. It's possible I'm going down the wrong track or that there is already a better way to handle these cases. It would also be great if we could get some buy-in from the TypeScript language to solve this, if needed.

Some possible ways TypeScript could be improved in this area:

  1. Fix #4336
  2. Make it so that __MyLib only exists as a namespace and not as a value, either through convention (prefixed with __) or through additional syntax.

cc @johnnyreilly @vvakame

johnnyreilly commented

I'd love to hear what other people have to say about this - I'm in agreement that things are somewhat broken at present.

As a little digression, I've just taken over an app that is built using Browserify + Babel and written in ES6. I'd hoped I'd be able to drop TypeScript into the mix by just having it export ES6 which can then be processed by Babel but found that the definition file story was very wanting indeed. For now I've had to bail on the issue.

Thanks for writing this up @jbrantly - hopefully something good will result!

mhegazy commented

As a little digression, I've just taken over an app that is built using Browserify + Babel and written in ES6. I'd hoped I'd be able to drop TypeScript into the mix by just having it export ES6 which can then be processed by Babel but found that the definition file story was very wanting indeed. For now I've had to bail on the issue.

@johnnyreilly, Is the export * from namespace the only issue you ran into, or are there other issues?

johnnyreilly commented

Hi @mhegazy ,

I can't remember the details offhand. I'll reattempt and report back. - I'll try and give you access to a repo that produces whatever issues I face as well.

jkillian commented

👍 While I haven't looked into things enough to know if the initial proposal is the best solution or not, I've had difficulties working with CommonJS libraries when targeting ES6. A standardized, obvious way of doing things would be a plus.

glen-84 commented

I'm trying to use the type definitions for Gulp.

Are the only options right now:

  1. Target ES5/CommonJS and use the old syntax: import gulp = require("gulp");
  2. Target ES6, use the new syntax, but the definition must be changed to export default x instead of export = x.

?

For the 2nd option, if I send PRs to have various definitions updated, will that break applications using older (or even current) versions of TypeScript?

This is so confusing. 😞

patsissons commented

Just a note, I have run into this before when authoring various react related typescript definitions. the approach I have been using, which is similar to @jbrantly's concept, is to use the (somewhat new) export import syntax. This has the obvious caveat that you must export everything explicitly, but it does function within typescript.

/// <reference path="../../../typings/main/ambient/react/index.d.ts" />

declare namespace __MyLib {
  export interface ThingProps extends __React.HTMLAttributes {
    text: string;
  }
  export class Thing extends __React.Component<ThingProps, any> { }
}

import MyLibExports = __MyLib;

declare module 'mylib' {
  export import ThingProps = MyLibExports.ThingProps;
  export import Thing = MyLibExports.Thing;
  export default MyLibExports.Thing;
}