Emitted definitions contain undocumented /// <reference types=

[berickson1]

TypeScript Version: 2.0.0
I'm working on a module that imports react via @types. Upon compilation, I also emit definition files. The consumer of this package may or may not be using @types support. When I try consuming this module from a typescript project that doesn't use @types, I get the following error:
(1,1): error TS2304: Cannot find name 'react'.

It appears that this is due to definition creation emitting an @types specific reference in the generated .d.ts.

1. Is there any way to suppress this reference in the output?
2. Is this expected behaviour? It seems that I should be able to create a module written in typescript & emit definitions and make the consumer be responsible for having the relevant compatible typings available for a module.

Code

/// <reference types="react" />

Expected behavior:
Able to use module without @types support in the consumer

Actual behavior:
Compilation Error

[mhegazy]

Is this expected behaviour? It seems that I should be able to create a module written in typescript & emit definitions and make the consumer be responsible for having the relevant compatible typings available for a module.

The /// <reference types="react" /> is emitted if and only if a declaration in the generated .d.ts depends on a type form the @types\react. This guarantees the correctness of the generated file, and maintains the dependency on the package for your users.

If there is no real dependency at runtime, consider removing the public API that depends on react from your project, and the triple-slash reference would not be emitted.

if the problem is supporting pre-2.0 users of your API and this is just a point-in-time issue, I would recommend adding a post build step that strips out the reference. see #11586 (comment)

[berickson1]

There is a real dependency on react typings being correct, but this module is being consumed by a typescript 2.0 project not using @types yet. I don't think it's fair to force projects to upgrade their (potentially very large) typescript projects because as a module developer is using newer typescript features in their development cycle. It either puts the burden on the project to write nasty scripts that alter their own node_modules folder as part of the build process to strip this out or cut over to @types which isn't always feasible for a variety of reasons.

While I can strip this out as a one-off in my module, I'm not convinced it's a good precedent to set for people utilizing @types in their modules. My module package.json already has a peer-dependency set up, specifying the compatible versions that should be available, isn't that enough?

Additionally, there's no documentation as to the reference type emitting for @types. At the very least documentation should be updated to talk about this new reference type.

[mhegazy]

Additionally, there's no documentation as to the reference type emitting for @types. At the very least documentation should be updated to talk about this new reference type.

sorry about that. microsoft/TypeScript-Handbook#348 is tracking adding docs for this.

[Hotell]

The /// is emitted if and only if a declaration in the generated .d.ts depends on a type form the @types\react. This guarantees the correctness of the generated file, and maintains the dependency on the package for your users.

I don't think this works as expected. I'm currently struggling with very weird .d.ts outputs

this is my source file

// lang.ts

import * as ng from 'angular';
import { Subscription } from 'rxjs/Subscription';
import { Observable } from 'rxjs/Observable';
import { Type } from './type';

export interface BrowserNodeGlobal {
  //...
  angular: ng.IAngularStatic;
  //...
}

and this is declaration output:

// lang.d.ts

/// <reference types="angular" />
/// <reference types="chai" />
/// <reference types="node" />
import * as ng from 'angular';
import { Subscription } from 'rxjs/Subscription';
import { Observable } from 'rxjs/Observable';
import { Type } from './type';
export interface BrowserNodeGlobal {
  // ...
  angular: ng.IAngularStatic;
  // ...
}

I have no usage of node globals in that file, neither chai, chai is used in tests ofc,
this is super strange behaviour.

any ideas @mhegazy ? thx

[mhegazy]

the references to chai and node are not correct, this is a bug that should be fixed in the next release, see #11849. the general behavior of the compiler emitting /// <reference types ... /> for things you depend on is the expected behavior.

[Hotell]

right. thx for pointing me to right direction 🍺

[greglo]

I don't think it's fair to force projects to upgrade their (potentially very large) typescript projects because as a module developer is using newer typescript features in their development cycle. It either puts the burden on the project to write nasty scripts that alter their own node_modules folder as part of the build process to strip this out or cut over to @types which isn't always feasible for a variety of reasons.

Strongly agree, I hope you'll reconsider adding a first-class way of emitting compatible typings as none of the following options are palatable (seems like there is no 4th option?):

• Don't support consumers who aren't on TS 2.0 and @types
• Don't use @types myself
• Do manual surgery on the compiler output

[JohnWeisz]

Unless I'm mistaken somehow, this completely breaks local multi-project builds using npm:

• If I don't install the referenced typings in a consumer project, I cannot compile due to a "not found" error.
• If I do install, duplicate declaration errors spam up my process and I once again cannot compile.

Please provide a way to turn this off for good.