打字稿。 我可以区分编译时依赖性和运行时依赖性

Question

I'm using the CommonJS module conventions, since I'm targeting node.js for testing and using browserify to make a single .js file. Currently my modules are circularly dependent. What I'd like to do is to indicate that module value depends on module pnode , but only at compile-time. Ie any run-time dependence should be flagged as an error. Eg if module pnode declares a type T, then in module value , I'd like for a declaration like var a : pnode.T to compile without error, but an expression like new pnode.T() or a instanceof pnode.T would be in error because they creates a run-time dependence.

Is there a way to do this?

Motivation: Currently pnode and value are circularly dependent. That's ok as long as there is no circular dependence at run time. Circular dependence at run time causes a problem because node.js does not handle it correctly or even warn about it. My current code looks like this

File pnode.ts

import value = require('./value') ;

module pnode {

    export abstract class Label {
    }
    export class LambdaLabel {
        step() {
            return new value.ClosureV(this) ;
        }
    }
}

export = pnode ;

File value.ts

import pnode = require('./pnode') ; // Would like to avoid this.

module value {

    export class ClosureV {

        constructor( func : pnode.Label ) {

            if ( func instanceof pnode.Label ) // Would like an error here.
                console.log("a") ; else console.log("b") ;
        }
    }
}

export = value;

What I've tried. I was hoping that replacing the line

 import pnode = require('./pnode') ; // Would like to avoid this.

with

/// <reference path="pnode.ts" />

might do the trick, but it did not. There are various ways that I have considered eliminating the compile-time circular dependence, so that is my fall-back option.

Answer 1

If you compile pnode.ts with the declaration flag you'll get this .d.ts file:

declare module pnode {
    abstract class Label {
    }
    class LambdaLabel {
        step(): any;
    }
}
export = pnode;

Then when you reference it:

/// <reference path="test.d.ts" />

module value {
    export class ClosureV {
        constructor( func : pnode.Label ) {}
    }
}

You'll get the error you described: Cannot find namespace 'pnode' .
That's because the compiler knows that this .d.ts file represents a CommonJS module because it ends with export = pnode; .

If you remove that line (or comment it out) then the error goes away. You'll need to remove this line after every compilation (or have a script that does it for you) but it will work.

In any case I believe that having a third module which acts as a share module for the others will give you more flexibility, as you'll also be able to have common classes/functions that are available at runtime.
Not to mention that you won't need to take another action after compilation.