Why are all the d.ts files file modules?

[mbalex99]

Aren't the *.d.ts files generated supposed to be declaration modules?

I can't seem to reference /// <reference path="../node_modules/@reactivex/rxjs/dist/cjs/Rx.d.ts" />

In my typings.d.ts file.

[kwonoj]

Would you able to share small snippets to reproduce issues? I just tried below,

typings/typings.d.ts

/// <reference path="../node_modules/@reactivex/rxjs/dist/cjs/Rx.d.ts" />

index.ts

///<reference path="./typings/typings.d.ts" />
import * as Rx from '@reactivex/rxjs';
Rx.Observable.of(2).subscribe(console.log);

works fine with type definitions.

[mbalex99]

Well I'm trying to create a custom .d.ts file based off a prototype extension with RxJS and Firebase

I have a file RxFirebase.ts that has

Firebase.prototype.rx_observe = (eventType: string): Observable<FirebaseDataSnapshot> => {
    var self = this;
    return new Observable<FirebaseDataSnapshot>(observer => {
        var callback = (snapshot: FirebaseDataSnapshot) => {
            observer.onNext(snapshot);
        }
        var listener = self.on(eventType, callback, (err) => {
            observer.onError(err);
        });
        return () => {
            self.off(eventType, callback);
        }
    })
}

And I'm trying to create another _RxFirebase.d.ts_ to specify the shape of the prototypes that I've defined.

I'm using declaration merging to do this:

interface Firebase {
    rx_observe(eventType: String):Observable<FirebaseDataSnapshot>
}

I've included

/// <reference path="../node_modules/@reactivex/rxjs/cjs/Observable.d.ts"/>

But when I compile it says "Cannot find name Observable"

[mbalex99]

I'm pretty sure this is a bug because *.d.ts files will turn into file modules if there are imports at the root level.

[kwonoj]

I'm pretty sure this is a bug because *.d.ts files will turn into file modules if there are imports at the root level.

: Interesting, since current build configuration simply ask typescript compiler to generate type definition while building. Will try to look for anything could explain this behavior.

[kwonoj]

After looking for some references, I came to think this is expected behaviors with external modules.

from http://www.typescriptlang.org/Handbook

/// <reference> to an external module
A common mistake is to try to use the /// syntax to refer to an external module file, rather than using import. To understand the distinction, we first need to understand the three ways that the compiler can locate the type information for an external module.

The first is by finding a .ts file named by an import x = require(...); declaration. That file should be an implementation file with top-level import or export declarations.

The second is by finding a .d.ts file, similar to above, except that instead of being an implementation file, it's a declaration file (also with top-level import or export declarations).

The final way is by seeing an "ambient external module declaration", where we 'declare' a module with a matching quoted name.

The way refer type definition via ///<reference... is for internal, or for last case of ambient external module declaration in above quote, while current RxJS implementation is completely written in external module.

There is opened issue in TypeScript for this at here, (microsoft/TypeScript#1236, Add ability to generate ambient declarations for external commonjs modules) and 3rd party library dts-bundle (https://github.com/TypeStrong/dts-bundle) supports this externally while typescript itself does not support those behavior.

[kwonoj]

I'd like to suggest to use direct import as current typescript suggests, or use bundling if ambient declaration is necessarily required. Since this is depends on TypeScript implementation behavior, I'd like to close issue on RxJS end.

[kwonoj]

After giving another thought bit more, it may be considerable to bundling type declaration on RxJS end.. leaving this issue opened for a while to gather opinions.

[mbalex99]

Yes I understand the bundling concept,

It's just that I'm trying to describe the shape of a method after applying a custom prototype.

Isn't it bad to have import statements in *.d.ts files? Having that import makes them file modules doesn't it? Doesn't that defeat the purpose of the *.d.ts definition functionality since they are there to help the compiler?

[benlesh]

I tend to use ES6 for most of my projects outside of this one :)

Perhaps @robwormald or @jeffbcross will have better insight into this?

[mbalex99]

@Blesh Unless I clearly don't understand something about the *.d.ts files, I don't think it has too much to do with ES6 as it does making TypeScript understand that you will have some sort of shape to a function, class, etc... by runtime.

If you prototypically extend an existing class, in the case of an extension method to have some RxJS abilities, you'll need to tell TypeScript that you've modified an existing interface ahead of time. That's what I thought *.d.ts* files are for, a sort of casting right?

Therefore, turning a *.d.ts file into a file module by including a root import statement defeats that purpose doesn't it? I go through my typings folder in my projects and I cannot find one instance where the d.ts files use an import statement at the root level.

(I don't abuse this functionality but I use firebase references with RxJS SO frequently that it moves heaven and earth for me. Yes I could create an encapsulating helper class but that's just very verbose).

[benlesh]

@mbalex99 ... I guess I was saying I don't run into this issue, so it's hard for me to form an intelligent opinion on the matter one way or the other.

[mbalex99]

@Blesh ohh sorry I thought we were fighting.

[benlesh]

[robwormald]

This is a recent change to Typescript, and it very much aligns with their stated goals.

The declare module {} syntax is known as "ambient" modules, whereas the new ES6-aligned style is known as "external" modules. I did a write up in an angular issue here angular/angular#5248 (comment) - maybe give that a read over and let me know if it answers your questions, otherwise I'm happy to expand from there.

The basic idea is that import {Observable} from '@reactivex/rxjs' can be treated the same - by typescript tooling and ES6 / CJS runtime stuff.

[robwormald]

TLDR - if you're writing 3rd party modules on top of this library, author in TS using the new syntax and stuff should pretty much just work. Hand generating .d.ts files is so last year.