TS compile of go gives error TS2345

I have a working angular app that imports the go library like so:

import * as go from 'gojs/release/go-debug';

Everything using the go-debug version of the library is fine and works great. However, as soon as I switch to importing the non-debug version of the library (like this):

import * as go from 'gojs/release/go';

At this point, I begin seeing the following compile errors from the TS compiler:

(142,28): error TS2345: Argument of type '() => void' is not assignable to parameter of type 'Constructor'.
  Type '() => void' provides no match for the signature 'new (...args: any[]): Object'.

Is this because of a licensing issue? Is there a reason I cannot use the non-debug version of the gojs library? Our company has purchased the license for the library, but I’m relatively new to learning how to import it.

Compiling TypeScript has nothing to do with licensing, so that cannot be the reason.

What is the statement/line causing that error?

The lines that are failing are:

    go.Diagram.inherit(this.CustomLinkingTool, go.LinkingTool);
    go.Diagram.inherit(this.BarLink, go.Link);
    go.Diagram.inherit(this.BalloonLink, go.Link);

I am not clear on why they don’t have a compile issue with go-debug, but do with just go.

How is (for example) this.BarLink defined? Is it a function definition within a function that you define surrounding all that code?

I’m wondering if when importing from go-debug the TypeScript compiler is not finding go.d.ts, but is is finding go.d.ts when importing from go. Try copying go.d.ts to go-debug.d.ts in the same directory as the go-debug.js file, and see if importing from go-debug then results in the same compilation errors.

Let me give a bit of context to answer your first question. I have a top level component (Angular app that is webpacked) that has several methods.

@Component({
    selector: 'display',
    template: require('./display.component.html'),
    styles: [require('./display.component.css')]
})
export class DisplayComponent implements AfterViewInit {

The method with the errors that we’ve already seen is defined like this:

defineDiagram(): void {
    go.Diagram.inherit(this.CustomLinkingTool, go.LinkingTool);
    go.Diagram.inherit(this.BarLink, go.Link);
    go.Diagram.inherit(this.BalloonLink, go.Link);

The custom methods that are referred to are defined very simply as follows:

CustomLinkingTool(): void {
    go.LinkingTool.call(this);
}

// This custom Link class is smart about computing the link point and direction
// at "Parallel" and "Exclusive" nodes.
BarLink(): void {
    go.Link.call(this);
}

BalloonLink(): void {
    go.Link.call(this);
    //this.layerName = "Background";
}

The definitions of the methods (functions) defineDiagram, CustomLinkingTool, BarLink and BalloonLink all exist at the immediate direct level within the component class definition for DisplayComponent .

You have to call Diagram.inherit immediately after defining the ES5 JavaScript constructor function for your subclass. You cannot call it before the constructor function definition and you cannot call it after defining any methods or properties on the subclass.

If you were to define the subclass using ES6 class and extends, then you do not need to call Diagram.inherit.

I believe our code is doing the Diagram.inherit right after constructing the subclass.

However, the puzzling thing is why the first parameter for the Diagram.inherit seems to have a compatible definition with go-debug, but not with just go.

Did you try copying go.d.ts to go-debug.d.ts to see if you get the compilation errors when importing go-debug?

I did what you said: copied the go.d.ts file (found in my 'C:\git\myapp\node_modules\gojs\release' directory) to a file named go-debug.d.ts in the same directory. I didn’t delete the original go.d.ts file, but left it in the same directory as you can see below

Doing this produces the same errors in the code, as you predicted:

ERROR in ./ClientSide/app/diagrams/display.component.ts
(142,28): error TS2345: Argument of type '() => void' is not assignable to parameter of type 'Constructor'.
  Type '() => void' provides no match for the signature 'new (...args: any[]): Object'.

I don’t understand what this means.

I suggest that instead of writing ES5 there, go ahead and use normal TypeScript language features. So something like:

import * as go from "gojs/release/go";

class CustomLink extends go.Link {
    constructor() {
        super();
        this.routing = go.Link.Orthogonal;
    }

    hasCurviness(): boolean {
        if (isNaN(this.curviness)) return true;
        return super.hasCurviness();
    }
 
    computeCurviness(): number {
        if (isNaN(this.curviness)) {
            var links = this.fromNode.findLinksTo(this.toNode);
            if (links.count < 2) return 0;
            var i = 0;
            while (links.next()) { if (links.value === this) break; i++; }
            return 10 * (i - (links.count - 1) / 2);
        }
        return super.computeCurviness();
    }
}

thank you. Redefining them with full typescript classes worked perfectly for the release library ‘gojs/release/go’.

OK… now that I have it working with the regular go, once I switch back to using go-debug, my new class definitions for the LinkingTool or Link overrides have compile errors with go-debug:

export class CustomLinkingTool extends go.LinkingTool {
    constructor() {
        super();
    }

    // user-drawn linking is normally disabled,
    // but needs to be turned on when using this tool
    /** @override */
    doStart(): void {
        this.diagram.allowLink = true;
        super.doStart();
    }

    /** @override */
    doStop(): void {
        super.doStop();
        this.diagram.allowLink = false;
    }
}

That code throws compile errors on this.diagram because it says it can’t find its definition. Errors for that appear as follows:

ERROR in ./ClientSide/app/diagram/diagramLinking.ts
(22,14): error TS2339: Property 'diagram' does not exist on type 'CustomLinkingTool'.

ERROR in ./ClientSide/app/diagram/diagramLinking.ts
(29,14): error TS2339: Property 'diagram' does not exist on type 'CustomLinkingTool'.

This looks like precisely the same reason that my previous ES5 definitions were having a problem with the release go version- the D.TS file doesn’t exist for debug.

I proved this by doing what you previously suggested (I copied go.d.ts to go-debug.d.ts) leaving me with the previously mentioned 4 files in the ‘gojs/release/’ directory.

It seems to me that go should be released with both the go.d.ts and the go-debug.d.ts files to solve this problem.

Is this planned?

Because of this issue with the package not including a ‘go-debug.d.ts’, I have to manually add a workaround to my build process (otherwise, every time we upgrade to a new go package, or do an npm install- which is every build- then we lose the fix). This is not a good long term solution, but it works until you add a go-debug.d.ts to the package:

gulp.task('godebug', function (cb) {

    var nodeGoPath = path.resolve(__dirname, 'node_modules/gojs/release/');
    var goDebug = './go-debug.d.ts';
    var goDebugPath = path.resolve(nodeGoPath, goDebug);
    var goRelease = './go.d.ts';
    var goReleasePath = path.resolve(nodeGoPath, goRelease);

    if (!fileExists(goDebugPath)) {
        if (fileExists(goReleasePath)) {
            var currentDir = process.cwd();
            process.chdir(nodeGoPath);
            fs.symlinkSync(goRelease, goDebug, cb);
            process.chdir(currentDir);
        }
    }
    cb();
});

*note: While I believe the use of these node fs calls make it platform agnostic, I haven’t tested this on Mac or Linux. I am running on Windows, so other platforms may need to take that into account.

That’s probably a good idea. I wonder if we can put a symbolic link there, to avoid duplicated files and potential pull requests that would make them diverge.

That would be great if it came as part of the package, yes !

OK, I’ve updated our build procedure and it will be in tomorrow’s release. (Unless something surprising happens.)

Thanks for the great follow up on all this Walter.

I just saw the latest release. Looks like the new go-debug.d.ts file is in the github repo, but npm install does not get it on the target local repo. I wrote up details on github @ https://github.com/NorthwoodsSoftware/GoJS/issues/40

thanks

Yes, that’s my error. “Fixed in next release”, I hope.

Thank you! All is fixed on this issue now.!