Language service 1.4 in Visual Studio is not back compatible with the 1.1 compiler

[DavidRigglemanININ]

The following code compiles fine with 1.1 compiler (and even the 1.3 language service), but produces an error when using the 1.4 language service when the TypeScriptToolsVersion element is set to 1.1. The code below has to do with function overloading of sorts, and I can see why the type checking fails, but I thought it was a stated goal that upgrading to a new language service but keeping an old compiler should not break anything (as long as, of course, new features aren't used)

module Test {

    export function baseMethodOverload(a: string, b: number, ...arr: Int32Array[]): string {
        // Argument of type 'Int32Array[]' is not assignable to the parameter of type 'string | number'
        return baseMethod.apply(this, [a, b, "c"].concat(arr));
    }

    export function baseMethod(a: string, b: number, c: string, ...arr: Int32Array[]): string {
        return a + b + c;
    }
} 

[DavidRigglemanININ]

Changing the code to "new Array(a, b, "c").concat(arr)" fixes the error, but the real issue here in my opinion is not whether code changes are required to compile in 1.4, but rather that backwards compatibility was broken in the language service when the compiler version was kept the same.

[mhegazy]

The compilation will always use the toolset specified by the toolsversion property. If your tools version is 1.4 you will build with the 1.4 compiler if it is 1.1 you will be using the 1.3 compiler. If the desired toolset is not installed you will get a build error instead.

The language service has only one version and it is always the latest. 1.4 in this case. If your language service does not match you would get a warning that the behavior is different from build.

What is the tools version in your project and can you share your build log?

[DavidRigglemanININ]

My tools version is 1.1 as specified in the .csproj file, but am using the 1.4 language service since that is also installed in my development environment. Also, to clarify, the build itself is still successful. It's just that the error still appears in the Error List. Obviously, this is not feasible in a development environment for there always to be a false error. There is nothing in the build log (assuming you mean the console output window with the build tab selected) except for the one line containing the project to build.

[mhegazy]

OK. thanks for the explanation. I think i understand the issue better now. So are you seeing other errors in your code, or is the above sample the only issue you are experiencing migrating from 1.3 to 1.4?

With 1.4 we have introduced union types which made the compiler know better about the shape of arrays. in 1.3, the compiler typed [a, b, "c"] as {}[] as it included both strings and numbers, in 1.4 it become a little bit smarter and typed it as an array of numbers or strings (string|number)[]. Now that it has this view it is letting you know that a new of type int32Array would not match that.

You can get around this issue without having to change your code, by letting the compiler know what type you intended for the array:

return baseMethod.apply(this, (<{}[]>[a, b, "c"]).concat(arr));

[danquirk]

See #868 for details on these known breaking changes.