Issue with lib setting in the tsconfig.json

[remojansen]

So I'm targeting ES5 but I have added support for some ES6 elements using lib in tsconfig:

{
    "compilerOptions": {
        "target": "es5",
        "lib": ["es6", "dom"],
        ...
    }
}

You can see my tsconfig.json if you need it.

I'm using typescript@rc 2.0 and this is my gulp task:

gulp.task("build-bundle-test", function() {

  var mainTsFilePath = "test/inversify.test.ts";
  var outputFolder   = "temp/";
  var outputFileName = "bundle.test.js";

  var bundler = browserify({
    debug: true,
    standalone : "inversify"
  });

  // TS compiler options are in tsconfig.json file
  return bundler.add(mainTsFilePath)
                .plugin(tsify, { typescript: require("typescript") })
                .bundle()
                .pipe(source(outputFileName))
                .pipe(buffer())
                .pipe(sourcemaps.init({ loadMaps: true }))
                .pipe(sourcemaps.write("."))
                .pipe(gulp.dest(outputFolder));
});

You can see my gulpfile.js if you need it.

I run the build in AppVeyor and is failing only in one version of node:

nodejs_version=stable

You can see all the build logs here and the failing build here.

The error is:

TypeScript error: Error TS2318: Cannot find global type 'Array'.

This maybe think that it could be related with the lib setting in the tsconfig.json file but I'm not sure.

Thanks!

[cartant]

@basarat Are you able to suggest what might be causing this particular TypeScript error? The version of Node.js that seems to be the problem is 6.5.0. As the OP has stated, the builds are passing on several other Node.js versions.

[remojansen]

It looks like is behaving like if I used --noLib option but is weird because it only does that in one version of node.

[remojansen]

I've been testing and it looks like tsify uses noResolve even when I set it to false?

[cartant]

The options passed to createProgram definitely do not contain noResolve. However, when running your bundling with the debug logging enabled:

NODE_DEBUG=tsify,tsify-trace gulp build-bundle-test

there seems to be something amiss with the lib paths:

TSIFY-TRACE 10776: Parsing c:/lib.es2015.d.ts
TSIFY-TRACE 10776: Parsing c:/lib.dom.d.ts

Which could have a similar effect to noResolve, as the files would essentially be left out of the compilation. I'm looking into it.

[remojansen]

Thanks a lot for your help :)

[cartant]

I've found the problem. There is a new method in the compile host - getDefaultLibLocation - and if it's not there, TypeScript attempts to determine the location using the host's getDefaultLibFileName method. However, they way it does that doesn't work with the configuration that tsify uses.

This will be patched pretty soon.

Strangely, I cannot see how this could possibly be working on other versions of Node.js. I tried it on a VM with 4.5.0 and it failed. So your passing builds are something of a mystery.

[remojansen]

I tried in my laptop (OSX with node v5.8.0) and it was fine. Tried then with node v6.5.0 and it is fine too. There must be something weird in AppVeyor.

[cartant]

My laptop and VM are both Windows boxes. It looks like Windows is the common denominator.

I cannot say that I'm surprised; dealing with backslash replacement is an ongoing source of frustration with the TypeScript compiler. It looks like there's yet another place in which TypeScript's normalizeSlashes function needs to be called.

However, I still cannot see why it wouldn't fail on the AppVeyor builds that used other versions of Node.js.

[cartant]

Yep, calling normalizeSlashes on the result of getDefaultLibFileName also fixes the problem.

[cartant]

This should be resolved by #197. I've published 1.0.6 to NPM.

[remojansen]

Thanks a lot! 😄